Follow

software accesibility rant 

okay so this is totally not the reason why you should care about accessibility but I find it so weird that devs hardcore don't care about accessibility because of a very good reason: in 90% of the cases making something more accessible means "make it easier to parse for technology" and like, why wouldn't you do that? That's gonna make your own life so much easier. Testing, monitoring, benchmarking, debugging, all the things are helped by that!

software accesibility rant 

I think every dev should be forced to scrape their own website. Seriously, why are people against this? it's just helping yourself in addition to like, millions of people who could become users

software accesibility rant 

@secretlySamantha you likely know but to write it out for others: there's a trend in web user automation testing to look up elements specifically by accessibility attributes (the text itself, or an aria attribute). That approach means if you can write an E2E test, it's more likely it's accessible

software accesibility rant 

@CodingItWrong I actually did not know that, that's so cool!

software accesibility rant 

@secretlySamantha testing-library.com/ is the library I'm thinking of. I think #emberjs has a similar focus

software accesibility rant 

@secretlySamantha The main reason developers dont care about accessibillity is that it is more work.

Work which is – at least here in Germany – not ordered by the paying customer because it is not legally required and is not noticed (by the paying customer) when it is not done.

software accesibility rant 

@lilo oh absolutely, I guess I'm trying to say that I wish they'd understand that it's something that would also help themselves. Not that that would solve everything, but it would be at least something I guess

software accesibility rant 

@lilo @secretlySamantha In my opinion even incomplete accessibility measures are better than none at all, so just following good practice (using semantic HTML, not loading all the text in with Javascript, making buttons clickable) gets you most of the way there.

software accesibility rant 

@secretlySamantha [1/x] I can say something about web accessibility in this regard - often making things "pretty" and "UX-y" means deviating from the most natural and accessible markup / structure, especially with web forms. If you ask me, I'd just use native checkboxes, radio buttons, select dropdowns all the time. But rhey are not considered "slick" enough sometimes. So you end up breaking things and the trying (or not) to compensate.

software accesibility rant 

@secretlySamantha [2/x] some other basic things on the web don't have a "native" implementation at all - there is no builtin modal dialog with behavior like proper keyboard focus for instance (except alert, but that's no what I'm ralking about) despite the <dialog> element. So you end up patching up a UI toolkit in a markup language context.

software accesibility rant 

@secretlySamantha (sorry about the typos, typing on the phone)

software accesibility rant 

@setthemfree That's okay, I don't mind typos. That's an interesting point. I'm not a web dev so I don't really know about those things. I guess I have seen sometimes people "make" a button out of a div with an onClick or something which seems really strange to me? Why wouldn't you just style an actual button? (sorry if that are stupid question, this is not my field)

software accesibility rant 

@secretlySamantha I don't think there's a need to imitate a button anymore, they are fully styleable with css, so I just use a <button> whenever I need to. But checkboxes and some other elements are more challenging - the work-around is to still use a checkbox, but make a visual replacement for it while hiding the checkbox itself. Overall though, I think it's a deeper problem - html is not really a UI toolkit.

software accesibility rant 

@secretlySamantha @petrichor in general, the problem isn't "developers don't care". We've been through this with security

Some devs don't know about the topic

Many devs do know and care but don't understand what to do about it, and need clear guidance and tools that help, or it'll always come last after getting things working

Many devs know and care but their managers and product managers won't give them adequate time and resources, approve features/designs that make it harder or impossible to do things securely/accessibly, and otherwise screw the devs over

The "devs don't care" model doesn't help! They mostly DO care, once they're aware of the need. They just have to care about a great many other and often conflicting things. Go after designers and product managers, and the rest will follow

software accesibility rant 

@calcifer @petrichor That's actually a really good point and I'm kind of embarrassed I didn't think about this given that I'm currently experiencing it myself at my job (though on a different topic). I do think that it can be both though.

software accesibility rant 

@calcifer @petrichor I guess that making a case that it helps with things like testing could make a good case to managers as well to bring it higher on the list. It honestly kind of baffles me that UX and accessibility aren't thought of as the same thing because they really should be! (but I guess that's a different topic)

software accesibility rant 

@calcifer @petrichor another (reformist approach) is to try and sneak accessibility things into major frameworks like React. I don't actually have numbers on this, but I imagine that the number of buffer overflow exploits greatly decreased when people moved away from raw C and started using frameworks that didn't have that problem. I think the same can be said for accessibility.

software accesibility rant 

@calcifer @petrichor and to be fair, a lot has already been done. I've seen the idea about aria labels that "the best thing to do about aria labels is nothing. You're more likely to do something wrong when you try to do it manually instead of just using the built-in stuff." So while we still have a ways to go, there are things out there! This is true for users and devs alike, but the best way to ensure something is done is to make sure nobody has to think about it

software accesibility rant 

@secretlySamantha @petrichor the testing argument is definitely a good one. Finding devs with influence who can push on managers is a pretty good strategy too

But in my experience, you get a lot further if you can frame it from a customer point of view. Investing in accessibility makes the product easier to use for everyone, easier to test thoroughly (which reduces time to market and lowers UX bug escapes), and opens up new markets (people who require or favor accessibility)

And even FURTHER if you can influence purchasing to put accessibility features as scored reqs in RFP/RFQ processes.

software accesibility rant 

@secretlySamantha I have been making the argument for a while that 9 times out of 10, good accessibility comes down to just maintaining proper code health, AKA doing the stuff you know you should already be doing anyway. It doesn't win me any points, but is true!

software accesibility rant 

@objectinspace telling people to do the things that are good for them definitely doesn't win you any points sometimes! (just look at security) I'm with you and hopefully if we keep saying that we might see some change at least!

Sign in to participate in the conversation
LGBTQIA+ Tech Mastodon

*Due to increased bot signup, manual approval is required. Please write some applicable request text on signup.*

This Mastodon instance is for tech workers, academics, students, and others interested in tech who are LGBTQIA+ or Allies.

We have a code of conduct that we adhere to. We try to be proactive in handling moderation, and respond to reports.

Abridged Code of Conduct

Discrimination & Bigotry Won’t Be Tolerated.

We're not a free speech absolutist. We're not interested in Nazis, TERFS, or hate speech.

Respect Other Users.

This instance is meant to be a friendly, welcoming space to all who are willing to reciprocate in helping to create that environment.

Consent is Important in all contexts.

If you’re ever unsure, ask first. Use CWs where required.

Listen; Don’t Make Excuses.

If you’re accused of causing harm, either take some responsibility or ask moderators for help.

Use the Report Feature.

Our moderators are here to listen and respond to reports.



For more detail, please
Review our Full Code of Conduct


This instance is funded in part by Patreon donations.