DEV Community

loading...

What can a backend dev do to improve Accessibility?

Vicki (she/her)
Vicki was once a manager of aircraft maintenance and is now charming Python. She coded #VetsWhoCode bot & Code Questions bot. When Vicki isn't petting her cat, she’s throwing a ball for her dogs.
・1 min read

As a backend dev, is there anything you can do to improve accessibility?

Discussion (29)

Collapse
mattpopovich profile image
Matt Popovich • Edited

One danger that I don't think has been mentioned yet is seizure-inducing media. In the past, malicious users have been able to trigger seizures in users with epilepsy by uploading animated images designed to trigger them. This is a potential danger with any service that allows users to upload images, since even static images with certain dangerous patterns can potentially trigger seizures.

Detecting and removing seizure-inducing media could be one way backend devs can mitigate a major accessibility hazard outlined in WCAG 2.1 Guideline 2.3 – Seizures and Physical Reactions. For example, here's a Python project that aims to detect seizure-inducing media using TensorFlow.

Collapse
rhymes profile image
rhymes

Woah I knew nothing about this, I'm going to do some research. Thank you very much Matt!

This community is so awesome 😭❤️

Collapse
andersclark profile image
Anders Clark

This is eye opening. I wonder how the algorithm for detecting these images would look? I did a quick search and couldn't see anything obvious in the results.

Collapse
pclundaahl profile image
Patrick Charles-Lundaahl

TensorFlow implies neural networks, right?

Thread Thread
vickilanger profile image
Vicki (she/her) Author

TensorFlow may imply neural networks, but only if you're aware of it. There are so many languages, frameworks, and libraries that you really can't assume that everyone would know what a certain language-specific library does. Even if it's a popular one, we can't know everything.

Thread Thread
pclundaahl profile image
Patrick Charles-Lundaahl

Ah! Right, of course. Solid point.

Collapse
pclundaahl profile image
Patrick Charles-Lundaahl

That is a brilliant point! Thank you for sharing!!!

Collapse
vickilanger profile image
Vicki (she/her) Author

That's awesome! I've definitely thought about the hazards of some images, but I never expected there would be a project to detect them. I've starred it for future reference.

Collapse
pclundaahl profile image
Patrick Charles-Lundaahl

Just spit-balling here, but some things to consider might be:

Internationalization. Have your API allow the frontend to pass in a localization field as a header.

Let users change their email addresses, usernames, etc. easily.

Provide support for users who have names that don't conform to standard western conventions. Let people use characters beyond the standard ASCII range. Similar considerations should probably be given to phone number formatting.

Make it easy for users to delete their data.

Collapse
pclundaahl profile image
Patrick Charles-Lundaahl

To add to that, if you have any sort of profile data, give users the option to specify non-binary honorifics/pronouns, and maybe preferred name (if you need to capture their full/legal name for whatever reason). This lets you be more welcoming in marketing/support emails. Also, let people change their pronouns.

Another one: if you give users profile pages that are publically accessible via a named path, a) let them change that path, and b) don't allow other people to take that profile path afterwards (keep it locked to the original owner).

Right, enough of my blabbing. Stoked to see what else people come up with!

Collapse
vickilanger profile image
Vicki (she/her) Author

I definitely agree that people need to be able to change their details. I think it's also important to mention that users should be assigned a unique user ID#. I've noticed some sites don't do this and they use the username as the identifier.

Collapse
jamesrweb profile image
James Robb • Edited

Performance (content delivery & optimisation), internationalisation and do HTML (semantics) and ARIA (roles, states and properties) properly and don’t think it “works” and so it’s fine.. it rarely is. On the note of ARIA, it’s best NOT to use it actually since websites that do have 11+ more errors on average due to bad implementation per page and so learn using the aria authoring practices guide before touching that.

Source for the aria stat - I recommend reading the whole article though too!

Generally though the biggest one for a backend is the performance area, reducing page size, request payloads, etc helps with income inequality by keeping data use down for those who can’t afford much which happens in even “developed” markets and more generally is good practice to boot.

Collapse
andersclark profile image
Anders Clark

I think this is a really good comment. Most high-end web developers live in the western world or at least work in an office with high-performance broadband but most of the world is not so lucky.

Collapse
pclundaahl profile image
Patrick Charles-Lundaahl

+1 for reducing the amount of stuff you send over the wire.

Collapse
vickilanger profile image
Vicki (she/her) Author

I haven't learned much about ARIA. I'll take a look at the article.

Yes! I think we often forget that not everyone has access to the same quality of internet connection. Making sure everything is as efficient and as small as possible is important.

Collapse
jamesrweb profile image
James Robb

It's a worthwhile read and could take you down some interesting rabbit holes, highly recommended.

Collapse
nyamador profile image
Desmond • Edited

For backend there are no WCAG guidelines to follow but the most important things to me when I join a new project would be:

  1. Is the backend well documented ?
  2. Do they follow patterns ( example PEP 8 or if you're in the frontend world BEM would be a perfect example) ?
  3. Commented code🙂

Although these might not be necessary they really help when the project gets larger.

Collapse
alvaromontoro profile image
Alvaro Montoro

Commenting the code is a big one (and often overlooked).

Collapse
nyamador profile image
Desmond

Exactly!

Collapse
alvaromontoro profile image
Alvaro Montoro • Edited

These are more general development/usability ideas, but they may impact accessibility:

I'd say handling errors graciously. If there's an error, don't just crash and die, handle and recover from exceptions, provide information to be handled by the front-end. Having an app close without a message, or getting a blank web page without information is bad for everyone. Good and verbose communication between front-end and back-end will set up an environment that handles accessibility better.

Also, designing/managing the data with accessibility in mind and ready to adapt. For example, normalizing your database to support the internationalization of text, or being flexible with the data types you use (e.g. the classic "use varchar instead of number for a phone number" because you may get it in different formats).

Another one would be stop assuming all the work is/was done by the front-end. It doesn't matter how fancy the front-end is, there will always be users who interact in a different way or with a different browser. Some –if not all– of the data processing and validation that is done in the front-end will have to be done in the back-end too to provide a better experience (and for security too!)

Collapse
vickilanger profile image
Vicki (she/her) Author

I agree. We shouldn't assume accessibility is just a front-end thing. Giving good error messages can definitely be helpful.

The front-end is like a storefront, while the back-end is like the shelves with products on them. It's necessary for the storefront to have a ramp and handicap parking. It's equally necessary that things are accessible in the store too.

Collapse
pclundaahl profile image
Patrick Charles-Lundaahl

All fantastic points! I think the last paragraph, in particular, is really poigniant, and contains at least a couple of sub-points:

  1. Whatever work you can do on the server, or ahead-of-time, do it. Not everyone can afford current-gen smartphones, and modern JavaScript frameworks basically demand decent specs. If you can forego that in favor of traditional server-side rendering, I really think you make things more accessible (also, probably worthwhile to ask your frontend devs to try using CSS for animations first, before resorting to JS).

  2. If at all possible, develop API-first. This paves the way for doing things like providing voice assistant interfaces to your website/app. I think most people probably do this already, but I also think it doesn't hurt to say it again!

Collapse
rhymes profile image
rhymes

I can think of a few things:

  • learn the basics, you still need to learn what a11y is and how it works in the context of a web application
  • follow best practices, often backend devs generate HTML pages, those pages may be structured in a way that's not super accessible
  • embed tools in the app, there are tools that can check apps for static a11y issues
  • focus on performance: a slow site is an inaccessible site
  • talk with frontend devs and designers to have a better picture of a11y in the context of the company and how you could help them ;-) maybe it's just a question of helping building tools or better templates

Hope this helps!

Collapse
vickilanger profile image
Vicki (she/her) Author

These are all great! I think everyone should learn about accessibility. Performance is definitely important. What loads slow on a good connection is definitely not accessible. Many many people do not have access to a good connection. I think it's best if frontend devs, designers, and backend devs communicate.

Collapse
tombyrer profile image
Tom Byrer

Are worried about helping with accessibility on the front-end from the back-end?

Collapse
vickilanger profile image
Vicki (she/her) Author

No, I was just wondering if there were things backend devs should be doing for accessibility.

Collapse
tombyrer profile image
Tom Byrer

In general, 'accessibility' is applied to front-end code for a smallish percentage of folks who use the web site in less-optimal ways.

Backend?? Maybe ask around your company if anyone needs access help with your services?

If others need to read your code, I've heard that tab indentation helps over spaces; those how are hard of sight might have to increase the font size, or change the tab width to something that suits them more.

Thread Thread
andersclark profile image
Anders Clark

We all use the internet in a less optimal way: we're bipedal creatures who carry our consciousness in a gelatinous goo in a jar of bone on top of our bodies. You think an AI would be impressed by how it takes you SEVERAL SECONDS to read a post on Dev.to? ;)

Accessibility is not about adapting to a "smallish percentage", it's about building your app with the flexibility to take on the world's inhabitants in all its shape or forms, which does not mean "Normal and handicapped", it means:

  • Amazon Alexa.
  • Google-crawlers.
  • Humans with different physical variants.
  • Paper-printers.
  • Readers like Pocket.
  • Dolphins with computers inserted into their brains (not sure about this one, saw it in "Johnny Mnemonic"...)

Not trying to go full "Fuck you for not knowing about all the different variants of people who use the internet", just trying to point out that it's not about accomodating a small group of people who will never be able to pay your company back for your time, but about building something more flexible than pictures and text that looks ok on a mobile phone.

Thread Thread
vickilanger profile image
Vicki (she/her) Author

Love your explanation of a human. :D
I agree accessibility is about having the flexibility to accommodate everyone via the many many different technologies we use.

Forem Open with the Forem app