What about it? This doesn’t need accessibility.
The amount of ego doesn’t surprise me when the conversation of accessible code arises. Code, in any stage, from alpha all the way to production needs to be, should be, and can be made accessible. But a subset of the developer community, a rather large subset seems to think otherwise.
Thinking that there is no such thing as a disabled developer is on par with thinking we are the only living organism in the entire universe. That level of ego makes part of the reason why the Web and digital world is inaccessible. Those people would rather go to the grave thinking they are right, rather than be wrong.
We don’t talk about it much these days.
“This product uses AI and it will ship production-ready code!” but when challenged, they (the developer subset with egoism at the forefront) come out of the woodwork to attack people and argue with people that are pointing out the fact that is in fact a falsity.
That’s just one example of why without education and research, the Web is doomed to be inaccessible even more than it already is.
If those who egos aren’t checked at the door had their way, they’d ship their own computers and call it a day because, “It works on my machine!”. Hey Blaine, we’re not shipping YOUR machine.
If there were less ego from those that would rather die on the cross they make for themselves then maybe, just perhaps there would be a little more accessibility in the digital world. Yet, here we are and here I am writing what I can imagine will ignite some kind of firestorm in some ecosystem of keyboard wunderkind who can’t see beyond their own screens.
“Oh, I agree there needs to be accessibility but…” You ended the hate with the key word in that sentence. “But”. A “but” is an underlying statement to prove to yourselves you are correct. The reassurance that you are right and the other side of the argument is wrong no matter what the facts are or what the data is.
So when an accessibility professional says, “Hey, I just wanted to bring to your attention there are issues here. Accessibility concerns you want to address before making a a statement such as…” Stop going into a defensive posture and on the attack immediately.
That’s not an attack, it is someone telling you there are issues that need to be fixed to make your product, your brand, your app, your site, accessible to people with disabilities.
You created something more likely to make you money. That’s how tech works isn’t it? Then why would you shut out a subset of the population for whatever reasons because you didn’t want to make it accessible? Do a search for “disposable income of disabled persons”. You’d be surprised.
And to devs that wonder why it matters so. Think of these times when and if you ever become disabled because it could happen at any time to any of us.
Top comments (35)
This is a bit personal, but when I lost full use of my right arm, the barrier of attempting voice control for writing code was absolutely huge and just another layer of grief... I doubt I would be a developer today if physio hadn't worked for me. Now that I am hardly bothered by mobility or pain, it's so comfortable to just be able to use your IDE! There is such a big tooling gap.
But aside from my personal experience with disability, the right to information is a human right, ya gotta be accessible.
Exactly. I wonder how many times this comment you made has been read through the wave of people needing to nitpick the definition of "accessible code" and opine on something that they don't know of because they have asked what accessible code is.
Accessibility is a right, not a privilege. I see who and who does not practice this daily. Individuals and organizations alike.
Well isn't it some kind of accessibility as well to write an article in a way everyone can understand it and see what you mean?
Not all of us are native speakers and not all of us can look in your brain. German accessible Websites from our government provide an "easy language" mode where all articles are written in an easier to understand way because of this.
Accessibility can also mean to explain something well enough so others can understand what it is about. When many people don't understand what you are trying to explain one could think it's not accessible enough.
I was really confused what accessible code should be - that's not nitpicking, just confusion.
However thanks for explaining it (even if the only real dev accessible example was "not using utility first css" and writing readable code but that should be common sense)
On that topic, I've been using Hemingway editor for readability checks recently 👍
hemingwayapp.com
Uh that's cool, thanks for sharing 👍
I see the tag A11Y so I'll assume the OP is referring to the end result software product and not to the code itself.
In that regards, we have UX engineers, UX researchers and so on.
If a company doesn't include them and neither they add specifications in their requirements I can't see how can you blame the developers.
This is something I want to make super clear. A developer develops, period. Asking for stuff is business job, analyzing, rewording and putting together these requirements so the end result is better for the user -and most of the time for the business people and the company itself- is UX's job and QA's.
We can extend this more by adding details but it's mostly about it.
This is responsibility segregation that happens around two different workstreams:
1- Definition (Business, UX, UI, QA...).
2- Implementation (Architecture, development, data, QA automation, infrastructure...)
There's no reason for the second to invent requirements because the former didn't. They know what they want and you know how to code it.
An analogy to that would be
"imagine you really don't like pepper. You go to a restaurant and, as a client, ask for a specific dish without pepper and cooked in a certain way.
The chef, as a developer, cooks the dish the way he wants and adds pepper because he thinks this is how this dish is supposed to be prepared."
We have two people here and neither one or the other will be happy.
The client will complain "is it really that difficult to follow instructions??", the chef will complain and justify himself "I did what it should be made the way it should be made!" as well and overall this creates a toxic environment in which burnout is right at the corner.
Gosh most projects apply the same rule even to security!
"When the third party audits our software they'll come back with a set of security requirements and then we'll do what they ask for and move forward.
And that's my advice to be a bit more happy 😂
No. I'm referring to inaccessible code.
25 years in Accessibility and I have helped many developers actually write accessible code by telling them when they roll out the list of excuses why they can't with, "Do the Nike method and 'Just Do It'."
Code can be written accessibly and developers have zero excuses to why they cannot. Period.
Now that I've read your recent replies to other comments I understood what's that about lol I understand you wrote that text on a rant but dude, that one was hard to follow 😂
We did a test on using different stuff to mimic what a blind person would experience when using our products but never -yet and afaik- on the code itself, either way I believe the same rules apply for everyone IMHO, like "no acronyms nor abbreviations, CSS utility frameworks bad + if you use them by interfacing groups of styles then there's no point on using them in the first place, comments good for your future self and the rest of the team to understand what the heck was that about when it was coded back in the dinosaur era, and so on and so forth..."
If I understood it correctly this time then sure! 100% agree 😂
What developers do not understand is this. "Why are you all so bitter?"
We have been saying the same thing to developers, designers, PMs, C-suite, stakeholders for over 30 years we're a bit chippy.
Yes. and it was all over the place because there are many revolving parts going on, such as the ableism shown to the accessibility engineer who pointed it out on X.
So I zigged and zagged, but hopefully the gist is there.
Hahahaha honestly the post looks like something one could write after having a heated discussion for an entire working day, drinking 2 🍻 on an empty stomach and getting mad with the world because there's stupid people 😂😂😂
There are valuable comments trying to figure out what was that about though.
8/10 would do it again 😅
What is accessible code and how can code be accessible/unaccessible?
Is it about the code style or about functions you use/should avoid?
Is spaghetti code more accessible since a user has all code in one place instead of having to jump to different places?
I have the feeling this article just says "there is an error" but doesn't say what the error is.
Accessible code. e.g., Semantic HTML. Button elements instead of divs. Labels and accessible names being added to form inputs and labels. see linkedin.com/advice/3/what-best-pr...
Not only readable by a disabled developer, meaning the readability. Something utility-first frameworks that when mismanaged, leave a swath of code when the maintenance portion of the project is being done when the inevitable return to the project happens because of a lawsuit, or when something is broken and reported in a pull request.
I've heard screen readers read utility-first framework code and it's a nightmare. The issue which was the impetus behind this checks notes "rabble rabble rabble!". When a company touts "Production-ready code" in an alpha stage, I can guarantee it is not. Sure enough on a closer look, it wasn't.
When something is inaccessible, it's broken. That's inaccessible code. There are disabled developers out there as well as a disabled community as well. Not just blind, deaf, or in a wheelchair too.
Yeah, the article says the problem is with accessible code and I wonder if that's meant literally or if the author means more like accessible UI/UX facilitated or provided by code. I have no idea what accessible code would be, and this article is definitely an incomplete rant ("rabble rabble rabble!")
The above comment should clear up the "rabble rabble rabble".
Thanks for writing this! The intensity of the pushback and really ugly response in general to the accessibility side of the recent AI tool is... really disgusting.
I really appreciate the post, as it tries to give voice to a marginalized community.
To preface, based on your post I am assuming you are speaking of the actual code of an application be accessible to developers with disabilities. This is an interesting subject which I haven't thought about or researched deeply, and therefore I maintain a neutral stance. Below are my initial thoughts on the matter.
Accessible code sounds like a really neat idea that could benefit a lot of people. I'm confused on what makes code accessible, though. If I'm programming in Python, is it good enough to strictly follow PEP8 style guidelines? Is there an extra step I can take on top of that? What about other languages?
Maybe you also mean there's a lack of tooling available for disabled devs, such as high quality voice-to-text built for writing code. I can see that being the case, as the majority of the industry relies on traditional text editing via physical typing. It raises the question, who should develop this tooling? We may like to see big-name IDE providers do it, like JetBrains or Microsoft, or alternatively possibly OSS communities. What's required is that they have both the means and guidance to do so properly, as well as enough demand.
In all I think the intentions are good, I'm generally in agreement, but now we need to define where to go in a clear way. That might mean forming/joining a group of devs with disabilities, or starting work on new accessible tooling and onboarding new contributors, and so on.
Yes.
e.g., Any utility-first CSS framework that leads to an HTML element being 6 lines thick in your code editor, for instance. When I audit code for accessibility, I'm taking 10 minutes to find an ARIA attribute in a sea of
bg-green-300 border-green-600 border-b p-4 m-4 rounded ...Coding guidelines help. Utility-class frameworks that manage this well and keeps the readability above "good" helps. well-structured code, clean code, readability for the most part. Especially by screen readers.
No. There are plenty of tools. VSCode is readable via screen reader and other assistive tech like Dragon Naturally, I believe.
"Forming a group" specifically for the point you stated once again leads to "let's put this subset of the developer population over here and can be misconstrued as exclusionary. So I would suggest getting the thoughts of disabled devs and surveying them and ask those questions then putting it into documentation to do what you see fit with the information.
Thanks for the reply! Clears some stuff up.
I see where you're coming from with utility frameworks, e.g. Tailwind. Such frameworks typically provide some suggested mechanism of isolating bloated sets of tags, but they certainly don't promote the usage of them, and regardless they are hardly used and don't provide much better accessibility. This results in fast development, but maintenance and accessibility (which go hand in hand, as more accessible code is usually easier to maintain) becomes more difficult.
My point about forming/joining a group for disabled devs is also not intended to be exclusionary, and I think how I worded it came off the wrong way. My intent was to suggest that a group, currently existing or not, could be a helpful way to promote the adoption of accessible coding standards, and could include anyone, not just disabled devs. I realize now that the A11Y project is already doing that, I had not been educated about it before so I appreciate this discussion bringing it to my attention.
I think the issue is that people interpret the world via their own life experience.
It's a very hard task to put yourself in the shoes of someone else that have a very different life experience.
Are there ways to give devs tools to live the life of someone who suffers from lack of acessibility ?
Have a search for tools and that is your first disabling experience, if you find anything it will probably be a janky learning curve and/or behind a paywall.
There is a big community on insta and twitter etc of disabled advocates who share their experiences first hand.
Ask those people how to help them make it accessible. Life experiences aside, it doesn't take a life experience to write accessible code.
I enjoyed reading this, the only "accessibility" discussions and effort that I have been involved in relate to the finished product, not the code itself. And googling results are of same. Can you point out some materials for best practices please?
Here are some links I have:
linkedin.com/advice/3/what-best-pr...
developer.mozilla.org/en-US/docs/L...
w3.org/WAI/tips/developing/
Let's give the benefit of a doubt to those people. The reason why their products have little accessibility doesn't have to do with their ego, at least I don't think that's the root of the issue in an overwelming majority of the cases. I'm pretty sure it has to do with the following:
They don't know how accessibility works, how to make their products/services more accessible, or how to test the accessibility aspect. I can only imagine webdev being the only technology where this is easy, since accessibility is a big part of web browsers and is mostly handled by them, and they have a ton of automated tests that tell you how to improve it.
They don't have time or money to work on accessibility. Time spent on implementing accessibility features is time that could've been spent working on more critical core functionality. Same with money.
It's outside of their scope of work. Particularly if you're working for a startup or some other company, that isn't managed by you, you just have to do what you've been assigned to do. You can't just add features no one asked for simply because you thought they were important. The business has the final say in what should go into the product and you have to meet their vision. Also, the previous point still stands, so you just might not keep up with the tasks you've been assigned.
You shouldn't automatically attribute to malice something that could also be easily explained with other things. It's a toxic mindset and the source of majority of the drama I've seen in the developer community in the recent years. Everyone is different and has their own background, work, problems, etc.
Is this about code being accessible to disabled devs? What would be a way to improve here? Better speech to text, optimized for writing code, could help. But it seems you are unsatisfied with anyone saying "well I'm a jQuery maintainer, what could I possibly do about that?"
Code itself can't really be optimized for accessibility, at least not more than it needs to be optimized for general maintainability (concise code, good documentation etc).
Better tools, better coding, less spaghetti code, better readability. There is a start. See also linkedin.com/advice/3/what-best-pr...