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.
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.
Vicki, once a manager of aircraft maintenance, is now charming Python & Ruby. She has coded OpenGates.dev, #VetsWhoCode bot, Code Questions bot, & LGBTQ of the Day Bot. They love relatable writing.
Location
Richmond, Virginia
Education
Self Taught Python/Ruby, BBA in Small Business Mgmt, AS in Production Mgmt
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.
Vicki, once a manager of aircraft maintenance, is now charming Python & Ruby. She has coded OpenGates.dev, #VetsWhoCode bot, Code Questions bot, & LGBTQ of the Day Bot. They love relatable writing.
Location
Richmond, Virginia
Education
Self Taught Python/Ruby, BBA in Small Business Mgmt, AS in Production Mgmt
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.
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.
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!
Vicki, once a manager of aircraft maintenance, is now charming Python & Ruby. She has coded OpenGates.dev, #VetsWhoCode bot, Code Questions bot, & LGBTQ of the Day Bot. They love relatable writing.
Location
Richmond, Virginia
Education
Self Taught Python/Ruby, BBA in Small Business Mgmt, AS in Production Mgmt
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.
I like to build cool things, work with nice people and help others where I can. Currently I'm an engineering manager for a fintech startup and historically a serial founder & freelancer software dev.
Location
München, Deutschland 🇩🇪
Education
The Open University
Work
Engineering Manager @ Deutsche Fintech Solutions GmbH
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.
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.
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.
Vicki, once a manager of aircraft maintenance, is now charming Python & Ruby. She has coded OpenGates.dev, #VetsWhoCode bot, Code Questions bot, & LGBTQ of the Day Bot. They love relatable writing.
Location
Richmond, Virginia
Education
Self Taught Python/Ruby, BBA in Small Business Mgmt, AS in Production Mgmt
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.
I like to build cool things, work with nice people and help others where I can. Currently I'm an engineering manager for a fintech startup and historically a serial founder & freelancer software dev.
Location
München, Deutschland 🇩🇪
Education
The Open University
Work
Engineering Manager @ Deutsche Fintech Solutions GmbH
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!)
Vicki, once a manager of aircraft maintenance, is now charming Python & Ruby. She has coded OpenGates.dev, #VetsWhoCode bot, Code Questions bot, & LGBTQ of the Day Bot. They love relatable writing.
Location
Richmond, Virginia
Education
Self Taught Python/Ruby, BBA in Small Business Mgmt, AS in Production Mgmt
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.
All fantastic points! I think the last paragraph, in particular, is really poigniant, and contains at least a couple of sub-points:
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).
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!
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
Vicki, once a manager of aircraft maintenance, is now charming Python & Ruby. She has coded OpenGates.dev, #VetsWhoCode bot, Code Questions bot, & LGBTQ of the Day Bot. They love relatable writing.
Location
Richmond, Virginia
Education
Self Taught Python/Ruby, BBA in Small Business Mgmt, AS in Production Mgmt
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.
Vicki, once a manager of aircraft maintenance, is now charming Python & Ruby. She has coded OpenGates.dev, #VetsWhoCode bot, Code Questions bot, & LGBTQ of the Day Bot. They love relatable writing.
Location
Richmond, Virginia
Education
Self Taught Python/Ruby, BBA in Small Business Mgmt, AS in Production Mgmt
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.
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.
Vicki, once a manager of aircraft maintenance, is now charming Python & Ruby. She has coded OpenGates.dev, #VetsWhoCode bot, Code Questions bot, & LGBTQ of the Day Bot. They love relatable writing.
Location
Richmond, Virginia
Education
Self Taught Python/Ruby, BBA in Small Business Mgmt, AS in Production Mgmt
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
Woah I knew nothing about this, I'm going to do some research. Thank you very much Matt!
This community is so awesome 😭❤️
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.
TensorFlow implies neural networks, right?
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.
Ah! Right, of course. Solid point.
That is a brilliant point! Thank you for sharing!!!
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.
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.
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!
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.
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.
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.
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.
+1 for reducing the amount of stuff you send over the wire.
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.
It's a worthwhile read and could take you down some interesting rabbit holes, highly recommended.
For backend there are no WCAG guidelines to follow but the most important things to me when I join a new project would be:
Although these might not be necessary they really help when the project gets larger.
Commenting the code is a big one (and often overlooked).
Exactly!
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!)
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.
All fantastic points! I think the last paragraph, in particular, is really poigniant, and contains at least a couple of sub-points:
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).
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!
I can think of a few things:
Hope this helps!
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.
Are worried about helping with accessibility on the front-end from the back-end?
No, I was just wondering if there were things backend devs should be doing for accessibility.
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.
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:
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.
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.