dysphoric.dev

Accessibility is not a one-off project

When is the time for accessibility?

Always.

I know how important it is to build a minimal viable product. (Fun fact, you're probably looking at one right now with this blog.)
However, I believe a minimal viable product has to be viable. That means your grand ideas of amazing features you want to build at some point in the future should take the back seat and you should focus on building core functionality first.
In a business sense this is especially important since a minimal viable product may earn you money that you can use to fund further development.

But what does viable mean, actually?
Something that can earn you some money to keep the lights on and workers fed?
Something you would actually want to write your name on and be somewhat proud of?
Something that won't put off disabled people from your brand name because they weren't able to use it?
Something that will not be in SEO hell for months because the first release was terrible and now Google doesn't like you?

I believe all of the above. (Well the first and last one aren't really that important for a personal blog but for a business they very much matter.)
While it may sound difficult to combine getting to the first one as quickly as possible with managing the last three, in reality all of them are synergistic.

Disabled people are customers, too and even if it seems like we make up a small part of the population that one can ignore "at first", doing so is a really bad idea.
People tend to have other people they talk with, yes even disabled people commonly do that.
For a startup word of mouth is the most important kind of publicity. It's free, people tend to trust it a lot more than ads and in the best case it spreads exponentially.
Especially with a limited marketing budged companies need people to talk about their product and for that people need them to be able to use it.

If that is not convincing enough, maybe this will be: Accessibility is hugely important for search engine optimization.
Especially when launching a new product you need SEO because otherwise people will not know you exist.
To find out what you need to do to be listed further up on Google's result list, you don't need an expensive consultancy firm to tell you. Just run Google Lighthouse and fix the issues it will complain about. This is a very good first start and will put you above most other people that don't think too much about this.
When you have run Lighthouse you will see that a whole category of issues is labelled "Accessibility." Fix those issues first because not only will it make your product be seen, it will also be usable to more people.

Also, I as a developer don't want to be associated with bad, inaccessible products, and forcing me to be may be one of the quickest way to lose me as an employee.
I know this is a personal thing but I doubt I'm the only person who thinks like that.

Okay, we won't launch with an inaccessible product but we can surely just go over our product and fix the issues during a last sprint before launch?

Happy to hear about the first part, imaginary person I invented to make my point. However the second part is not a good idea either.
If you hack together a product and only patch in accessibility after the fact, you will end up with devs that are used to building inaccessible products. You don't want that.
Sure, having one or two accessibility sprints is a very good start if there already is an existing code base. You should absolutely do that after investing some time to teach your devs what they should keep in mind to build accessible products.
But this should be done asap to avoid making the work harder at a later point.
After the existing code base has been fixed, processes should be implemented to avoid new inaccessible code to be pushed:

• Devs should take great care during code review to reject every PR that has accessibility issues.
• If possible, automated accessibility testing (Take a look at LighthouseCI for something that is free to use) should be implemented
• If one can afford it (and doing so should be a priority) have people who aren't devs do QA (bonus points if they're disabled)

But you're not perfect either

Absolutely right. This blog was written 10 months ago during a noisy conference.
Back then I was still an apprentice (although my final exam was just two weeks in the future) and since then I have learned a lot of things.
Once I find the time I will do an "accessibility sprint" to fix any issues this blog has. The important part is that any new code I write is as accessible as I can make it at the time.

This is a personal blog, not a commercial product. Still, if someone cannot use it because it's inaccessible, I truly am sorry. I've got the email address accessibility(at)dysphoric.dev setup so that people can always send me their complaints - if you haven't already you should add a similar thing to your website.

This post isn't to tell you that anything that isn't perfect is bad. I'm writing this mostly to sensitize more people to care about accessibility during development and not as an afterthought that is commonly forgotten.

When I was a lonely, unpopular and generally pretty confused child, the internet was a place where I could be myself.
It helped me figure out who I am and made me accept that.
I am privileged in that my disabilities did not prevent me from doing so.
I want as many people as possible to able to have these experiences.
I want a more accessible internet.
For everyone.