Disabled people create content for the web. They have jobs that require them to use certain programs or work in a department that has a specific set of tools or workflows. Disabled people are even developers.
Imagine never knowing if the tool you need to use to create a blog post or add a course lesson or submit a comment will work. Imagine finding out two thirds of the way through working, everything you did won’t be saved because the tool wasn’t built correctly.
Any tool that lets you create content on the web has to be accessible, and it needs to enable you to create accessible content with it. There’s even a whole separate set of guidelines to help, called ATAG (Authoring Tools Accessibility Guidelines).
Check out the video on YouTube or the audio on the podcast.
Your product doesn’t have to be perfect. The biggest issue is when you know your product is not accessible and treat any request or bug that relates to accessibility like a feature request. You don’t wait for people to request that a tool or feature be accessible. Just like with websites, it’s best to develop your product to be accessible from the start. And when an issue is reported, you investigate it.
The burden should not fall on the user to have to reach out to the creator of every product they use to tell them they’re not able to use it. Especially when a majority of the time they’re told it’s “not a priority” or to “submit a feature request.”
There aren’t any disabled people using my product.
The number of disabled users who might use your product is not a factor in whether or not you need to make your product accessible. Just like we don’t consider the potential number of disabled people visiting a website as a factor for whether we make a website accessible or not.
If you don’t make your product accessible — for instance, if people using only a keyboard can’t actually use your product — you can’t then claim that keyboard-only users aren’t using your product as a reason for not “investing the time.” They’re not using your tool because they can’t.
Waiting for people to tell you they can’t use your tool isn’t enough. Treating it like a “feature request” is exclusionary and not the way to approach development of a web content tool. Just like accessibility should be a consideration at the beginning of a website project, the same goes for the creation of a website tool.
I’ll take care of accessibility when it’s profitable enough.
There’s not an “economic argument” to be made here, and it isn’t something you can deprioritize as if it’s a feature you’re adding onto your product. You build your tool so people can use it.
And when someone points out an issue with your product, you don’t wait for it to become a formal request or turn it into a roadmap item that gets voted on. It should be treated as a critical bug that gets investigated.
By waiting to address accessibility if and until it’s deemed profitable enough, you’re simultaneously telling users that you don’t care about their user experience and locking out an entire population of people from using your product.
A disabled developer or web content creator should be able to use the same tool as someone who isn’t disabled.
It’s mostly accessible, but we want to include some other stuff.
As long as there’s some way for a person to complete the same action, you can provide an alternative method for it.
Drag and drop features need to be usable without a mouse. Context menus should be able to be opened and the options inside need to be selectable without a mouse.
When you’re adding new features to your product, they need to be accessible, too. Innovation is great, and it’s exciting when new things get added. But these new features need to be tested for accessibility just like the initial product.
The new feature shouldn’t get launched until it’s accessible, even as a beta feature. Disabled users can’t test the new feature without it being accessible.
I’m extending something that isn’t accessible, so I’ll worry about it when it is accessible.
If you’re extending something — creating something that gets added on to another product — the accessibility of that original tool is not a determining factor in whether or not your extension needs to be accessible.
Instead, you should be developing your extension as you would any other tool — by starting with accessibility. And you should be pushing the creators of the main product to address their accessibility issues and build accessibility into their product.
You’ll also benefit from the fact that once that main product does become accessible, your tool won’t need to be redeveloped.
We don’t want to limit creativity.
Accessibility has nothing to do with whether or not someone can be creative. It’s important that the tools you’re building enable people to ensure the content they’re creating is also accessible.
If someone can add images, there should be a place to add alt text. If you provide the option to select colors, you should notify users when their color choices don’t have proper contrast.
There are a number of ways to approach this, including providing relevant links so they can learn more about what these things mean.
A disabled person already told us our product was ok.
You took a great first step by having disabled users test your product. But what works for one person may not work for everyone. It’s part of the reason why accessibility is an ongoing process.
If someone submits a bug saying they aren’t able to do something, it’s important to follow up like you would with any bug report to make sure you’re providing as accessible of an experience as possible.
It’s even possible that fixing an accessibility issue that someone brings up could make it easier for that initial person to use the site, even if they were able to get by as it was before.
There are a number of ways to solve accessibility issues, like allowing people to enable or disable certain features or creating ways for people to extend and personalize your product.
Your tool should be accessible.
When you include accessibility in your web content tools, you’re enabling everyone to create their own websites, to do their jobs, to share their knowledge, and to participate in online communities.
