EevisThis question might feel a bit strange. Backend developers often touch the UI less, so they don't need to care, right? I beg to differ. This blog post will look at some practices backend developers can do to ensure the accessibility of the end product and documentation.
We'll look into API structure, documentation, performance aspects, and backend rendered pages. This is in no way an exhaustive list of things, and there is definitely more backend devs can do, but let's start with these four.
API structure
There is actually a huge opportunity to improve accessibility when building APIs. This opportunity comes from reusable structures and ensuring that the content requires accessible roles, names, states, or properties. Also, APIs can enforce requiring things like having captions and transcripts for videos and audio content.
One concrete example of API supporting accessibility is images. When uploading an image, the API should require an alternative text or information that the image is decorative. So, when validating the sent input, there should be a check for having the alt-text (for example, as a separate parameter). And if the image is purely decorative, and thus the alt-text is not needed, then, for example, a boolean value indicating that.
Localization is another thing that helps with accessibility. Enabling people to use products in their native language can make barriers smaller. When designing an API, developers should consider localization and how that API can support it. I know there are cases where another service handles localization, or it's handled in the front end, but it's rarely only about the texts on the site. Often values stored in the database should be localizable too.
Documentation
Another aspect where backend developers can help with accessibility is the documentation. There are two sides to this: The site or platform, and the content.
Platform or Site
First of all, the site where the documentation is should be accessible. So, for example, the site uses semantic HTML, is keyboard navigable, has colors that have enough color contrast, and has a logical and clear structure. You can read more about web accessibility from Web Accessibility Initiative.
Many projects use readymade solutions to render documentation. Whether it's a Swagger-type documentation containing only endpoints and inputs, or a more extensive platform with text, it's not usually built from scratch. So, it's essential to check that the platform actually is accessible.
You can use automated testing tools and also do some manual checks. These blogposts contain resources for development, but there are tools and assessments you can do for any site.
I'm in the process of doing some quick accessibility tests for different documentation tools, and I will write a blog post about the results. So stay tuned!
Content
Another important thing is that the actual language in the documentation is accessible. You can use some of the principles of plain language. Let's look at what this means in practice.
If the documentation has longer text blocks, try to follow these instructions:
- When you address the reader, use "you," not passive.
- Avoid complex sentences and unnecessary words.
- Write the most important information first.
- Write short sentences and paragraphs.
Also, if the documentation has images, remember to add alternative texts explaining the image's message. If the picture is purely decorative, add alt="" to it. Here's more about alternative texts to images.
If you add videos to the documentation, add captions and a transcript for the video. Many people tend to watch videos without a sound on, so it serves all. The Deaf, Hard of Hearing, and Deafblind depend on the captions and transcripts to know what's happening in the video. Here's a resource where you can learn more about captions.
Also, it's good to pay attention to the structure of the content. Use headings correctly, meaning when you have a title, annotate it as such. Also, use correct heading levels. I just found a good tool for content creators to check some accessibility aspects, and I think it would work with documentation as well. The tool is called Sa11y. Go and check it out!
Performance
Another aspect to consider is performance. It is essential that the frontend does as few heavy calculations as possible. Not everyone has the latest devices with lots of memory and calculation power.
I know some people argue that this doesn't really matter. But it actually does. It matters for the user. If many things are happening in the front end, the user's internet is slow, and they have an older device, this might mean that nothing happens for them for a long time. That, in turn, means the site doesn't work for them.
If the site is something they can leave, they probably will. But what if they still need to use the site? Let's say it's the only way to book an appointment with a doctor, which they desperately need. If the site is slow and unresponsive, they might start trying to click things to see if it works. And when it finally starts working, all those things happen - and they find themselves in a totally wrong place. That's frustrating. But it can also be a huge barrier. Many don't just have the bandwidth needed to fight these non-working sites.
I want to remind you that many disabled people live in poverty. For example, in the United States, about 26% of disabled people lived in poverty in 2019. (Source: Disability Statistics.) They might not have the newest iPhone or the most high-performance computers.
And even if you don't live in poverty, it doesn't mean you'll always have the newest and most performant devices. I think this is often a bias we developers have - "Works on my computer" is so much more than being unable to reproduce a bug. It's also a privilege because we have our macbook pros and the newest phones to work with, and we build apps that work with them.
Backend-rendered pages
Another factor for the backend developers and accessibility is backend-rendered pages. They need to be accessible, too, like any client-side rendered pages.
Okay, I know; frontend developers handle the back-end-rendered pages in many cases. But there are always some times when backend devs need to create small pages. Those pages need to be accessible too.
So, even if you're a backend developer, I'd suggest looking into web accessibility and learning the basics. If you need to choose one topic to start with, I'd say semantic HTML. Not everything is a <div> - many other elements communicate meaning to assistive technology and work better. From there, I'd suggest continuing with keyboard navigation and other ways users use their devices - not everyone uses a mouse.
Wrapping Up
So, in this blog post, I've been discussing ways backend developers can improve accessibility. There are four points I've been talking about: API structure, API documentation, performance, and backend rendered pages.
These are not the only ways a backend developer can (and why they should) contribute to accessibility. Do you have some ways in mind? I'd love to hear your thoughts!
