Happy Global Accessibility Awareness Day!

On Thursday 20th May, we celebrated Global Accessibility Awareness Day. Not only did we champion the importance of creating a more accessible world for all but we also celebrated some fantastic recent achievements that are helping us achieve this mission. Here, I’d like to share our experiences of trying to make the TOPdesk product more accessible over the past year – and will also be offering some tips to help product developers and service managers on their own journey towards creating a more accessible future.

Accessibility and Service Management

The TOPdesk platform helps service organizations coordinate and offer their service delivery to end-users. End-users can engage with the platform to resolve issues and request certain services that are available to them. Naturally, that group of end-users is very diverse. It can be fellow employees at an internally-focused service department, but it can also be civilians living in a municipality, or students at an educational organization. There is no doubt that a good number of these end-users will struggle with the language, interfaces, input devices or other elements used to provide these digital services – aspects of the product that many of us might simply take for granted.

We recognized that more could be done to make TOPdesk accessible to all our end-users. With that in mind, we set about addressing these accessibility concerns.

(Re)building an accessible portal

Let me start by saying that if you happen to be building a product right now, please make accessibility a quality criteria. It’s so much easier and cost-efficient if you learn about – and deal with – this subject early on.

We didn’t have that luxury. For TOPdesk, accessibility meant taking our existing portal and revisiting many of the choices that we made in the past. And boy did we underestimate the scale of this project.

The process of making aweb-based tool like TOPdesk accessible is defined quite clearly in the excellent Web Content Accessibility Guidelines (WCAG). In intricate detail, they tell us which interactions to avoid or promote, and the reasoning behind it. Importantly, it leans quite heavily on proper and semantic usage of HTML syntax. A heading should be defined as a heading, and not a bold piece of text. A bold text might do the job visually, but assistive software doesn’t have a clue that this bold text is in fact meant to be a heading.

So with that in mind, we should take our HTML, remove all the DIVs and other syntax that was misappropriated, replace it with the correct syntax (and perhaps an aria-label here and there) and we will be all done. Right?

Sadly not.

Making TOPdesk accessible

Technically accessible isn’t the same as functionally accessible. While each individual element in the interface might be described accurately, that doesn’t mean the sum total works well. How does someone who’s blind know where to go on a page? You need structure and context. If someone zooms in a lot to compensate for limited eyesight, they’re likely to cross a responsive break-point.

This often occurs when we strip some less-than-critical functionality from the interface to keep things compact, but by doing so, we unintentionally discriminate between users. And what if the user runs into an unexpected situation, like a missing field in a form submission; do they have the context to get themselves out of that situation?

Reading the WCAG was revelatory. Importantly, it meant that several development teams had to quickly get to grips with a range of accessibility-related scenarios – understanding precisely what issues existed within the TOPdesk platform and how we could redesign them going forward. I’m proud to say that we all stepped up to the challenge. In the past year, we’ve made the changes necessary to say with confidence that organizations can use TOPdesk with all their end-users, no matter their specific accessibility requirements.

The improvements we made

Some accessibility changes have been met with universal approval. Full keyboard accessibility, for example, was warmly appreciated by our own support department, simply because some prefer using a keyboard over a mouse. Such a by-catch isn’t uncommon; many accessibility-focused features benefit all users, regardless of their abilities. A second example was the addition of custom color scheme support, making it possible for users to change the interface appearance. With the default provided you can have a ‘dark mode’ for TOPdesk: essential for those sensitive to light, and a nice-to-have for those who have most of their professional tools in a dark color scheme.

It’s not all sunshine and rainbows, though. We needed to make sure that responsive breakpoints didn’t cause functional changes, meaning the desktop-interface had to be drastically rearranged. A side-panel moved from the right to the left, because in a narrow view-port, it came on top of the main content. This made it functionally consistent. While it’s rare for people to be hindered by this inconsistency, the change we made caused significant disruption in the interface for millions of end-users.

Is TOPdesk done now?

Yes and no. Yes, we have accomplished what we set out to do; the self-serice portal is an accessible environment, with a positive audit and published results.

But also no, not by a country mile. TOPdesk is much bigger than just the portal, with many parts of the software requiring a thorough re-write before they can offer a truly accessible experience.

Plus, we still have a lot to learn that can only come from experience. These are often hidden in the small details, such as leaning on a common understanding of symbols in our software that presumes experience with the internet, or the use of undescriptive headings and links in a blog like this (though I’m trying!).

And then there are bigger issues to consider. For instance, we’re currently working on a graphical process designer, which is typically a desktop interface with drag-and-drop interactions. But this begs the question: how can we make that responsive and keyboard-friendly? Or should we make a secondary interface? Unfortunately, we do not yet know what the best approach is.

But we want to get better, and we’re certainly moving in the right direction. TOPdesk now considers accessibility to be a fundamental requirement of anything new that we build. In time, this means that nobody – whether they are end-users, operators, managers, or more – should experience obstructions within the TOPdesk platform.

Accessibility and you

With all that said about TOPdesk, I have not addressed the most important factor in all this: you. An accessible platform is meaningless without accessible content. If you offer services or content, consider these quick tips:

1. Provide structure through the proper use of headings, lists and other elements. A bold text isn’t a heading, while a bunch of lines with a dash in front of them isn’t a list.
2. Language should be easy-to-understand for all readers. You have probably read a legal document that was about as clear as if it were written in a foreign language. For some people, many texts are like this. Straightforward use of language helps everyone understand what you’re trying to say.
3. Meaningful headings and links. This is one I still find a bit tricky, but try to consider your headings and links without context. Would you still understand them by themselves? Avoid ‘click here’ calls to action, for example.
4. Image alternatives. It’s not uncommon for a key piece of information to be captured in an image, or worse yet, for there to be an image that contains text within it (this is especially annoying if you want to copy part of it). Don’t. Use images merely to support your content, and provide an alt-text to explain what’s there.
5. Provide media alternatives. If you have made content available in a video, provide captions. If it’s a podcast, provide a transcript. Technology is making massive strides here, so the effort required on your part should be a fraction ofwhat it used to be just a few years ago.

And if you want to take it a step further, here are some pointers.

1. Make the exception the norm (where possible) to avoid ‘special treatment’. Remove all doorsteps in the building, make every desk height-adjustable, and make alternative input devices readily available.
2. Document your accessibility policy and publish it. Force yourself to take a look at your organization and take a stand in your ambitions. Make a policy and live by it.
3. Have someone specialize in accessible text writing. Organizations produce a lot of content, so it’s obviously worthwhile to have someone who is dedicated to writingaccessible content. Even just mastering the basics will make a hugedifference.
4. Hire someone with disabilities. Not as a guinea pig, but as a challenge to the organization. Expand your talent pool and look outside the common boundaries. You might be pleasantly surprised about who gets brought to the table.

Closing remarks

If you got here, thanks for your time. Even if you are not actively involved with product development or service management, keep accessibility in mind in all your professions, especially during this crisis in which we rely so heavily on online content. When creating a presentation, make sure texts have proper contrast. Play around with some of the awesome features Microsoft and Apple have been introducing, like live subtitles in Teams meetings or AI-assisted alt-texts for images.

And most importantly: spread the word about the importance of accessibility. We’ll get there together.