Many in this holiday season have a tradition of giving to those we love. This often extends beyond our immediate circle to supporting those in need. Each day of 24 Accessibility has been a gift from an expert. Each has useful information about inclusion you can apply to your personal or professional life.
Except this one.
It is a safe assumption that if you have come across this article that you already know about accessibility. Likely enough to start to contribute back. I am not encouraging you to write an article, propose a talk or organize an office awareness day. Those are all great things. I want to see more of them, but I would like to challenge people to try a new way to give back. An approach that may at first seem a bit like volunteering in a mission or food bank. Something that may become incorporated into your online work.
Make the internet more accessible by default
I want you to help make this happen. It is something that everyone thinks would be a great idea, but very few seem to be engaged in. It’s not that people don’t want to, but it isn’t a priority for most organizations. Web accessibility budgets are generally spent on site-specific fixes and individual accommodation. This makes sense as there are risks for organizations with inaccessible sites. Organizations have only so much to spend on fixing these problems.
Except that most of the internet is built with open source libraries.
There are always going to be developers that take short-cuts and clients that just want something flashy and new. This won’t change but many barriers to people with disabilities are caused by the system. Patterns get repeated by developers over and over. If a developer, working with a deadline, has to look up the current best practice, it won’t happen.
Let’s make it easy for everyone to do the right thing
I started contributing to Drupal about a decade ago now. At that time, I knew as much as the average reader of this article. I found an error with an input form and thought I would report it. Little did I know that this would be the beginning of a long journey with web accessibility. I started documenting what I knew and found ways to keep nudging issues ahead. Since that time I have engaged in hundreds of issues in the Drupal community. We have tackled a wide range of issues and keep finding more ways to make it better.
You don’t need to be an expert to make a difference
I learned this in the Drupal community. There is so much information available about accessibility best practices that are available for free on the internet. There are pretty amazing automated testing tools. There are articles, videos, tutorials and books available. Plus there is a vibrant community on Twitter, Slack and forums like WebAim and Google Groups. The volume and changing nature of accessibility can easily overwhelm people. None of them are perfect, and that’s ok. Where possible put up a link to the resources that you think provide useful guidance. The date written matters, but there are some articles that are as true today as they were 20 years ago.
Start small and start today
Start with the web tools you use. This might take some investigation, but try and find out if it is built with WordPress or Joomla. Is the theme based on Bootstrap or Material-UI? Do you use CKEditor or TinyMCE? Find a library that you use that has an open, public issue queue that you can contribute to. It could be Firefox or NVDA. Find some software that you use that is supported by an open community. If it is actively maintained an open source community will have way to submit bugs and feature requests. To submit one you will most likely need to sign up for an account.
Find an issue that interests you to help keep you motivated
Take some time to look at the existing issue queue to see if there is an “accessibility” or “a11y” tag tracking issues. It is very likely you will find issues that others have posted which are not resolved. Take the time to investigate some of these and see if you can replicate the problem. Perhaps there is a patch (a piece of code) that can added to the code that removes the barrier. Maybe, the issue isn’t described very well or doesn’t have a screenshot that illustrates the problem. You don’t need to fix the problem to be useful. Find a way to add something to the discussion thread that is new, related and useful.
Demonstrate that accessibility matters to users
Simply posting on an existing issue will generally do a lot to remind people that this is an unresolved bug. Adding to the knowledge around the issue helps ensure the right solution is selected. Maybe the issue is already fixed, but just not updated. Everyone loves to have an issue crossed off their list. Developers love making their code better and more robust. Keep in mind that it is unlikely that maintaining this project is someone’s full-time job. Attitude matters, so remember to be thankful for the contributions of others. Carrots often work better than sticks. It often helps to add a bit of human context for why these WCAG guidelines matter.
Discover new issues
It’s not that hard to find ways to improve any active software project. Even with Drupal where we’ve been making steady improvements for over a decade. There are always new issues in active software projects. Maybe you already know some through the testing that you have done with your own site. Perhaps it is looking at a demo of the project that is available online. Worst-case scenario, you’ll need to install something on your computer to experiment. Most active open source projects will be open to helping you get involved.
Don’t be afraid to make mistakes
Accessibility is complicated. There may be conflicts with usability best practices. You will find that most assistive technology is not built to a common standard. There will be conflicts with browsers and operating systems. Some solutions proposed by some accessibility experts will contradict that of others. There are going to be people who use assistive technology in ways you didn’t expect. That is ok. Get involved and experiment. Build a good argument for the changes you want based on your research. Provide links to authoritative sources like the W3C. Provide examples of precedents used by other projects like Drupal. Point to issue queues in other projects where this is being worked on. Do your best with what you know and be open to learning more.
You aren’t alone and we can fix this
Technology is changing fast and accelerating. The only way that we can build a future where we have accessibility by default is to have more people involved in creating solutions. There is so much work done with software innovation. We need an enthusiastic culture where we all contribute where we can to the common tools we use. Given the rate of change, we need to look upstream and see we aren’t wasting our efforts rebuilding the wheel. Look to similar projects to see if there is work you can leverage. If you don’t find your contributions valued, be patient. There are a lot of different projects out there, maybe another one would be more receptive.
Use automated tools but don’t rely on them
You can use automated tools like the WAVE Toolbar or aXe-Core to find problems most software. This catches a sizable percentage of the low-hanging-fruit of accessibility. There are often a lot of easily discoverable issues. You can often find more issues by tabbing through a site. Basic manual testing can provide very valuable insights into where problems are. Screen readers are more complicated. A problem for keyboard only users is also likely to be a problem for blind users. Unless you are already skilled using other assistive technology, don’t start testing with this.
Tag your contribution with #24a11yByDefault
We want to build the community of people who are contributing to open source projects. Please tag your contribution and/or tweet about it with the hashtag #24a11yByDefault – this way we can keep track of what this article inspires. Everyone can be involved in giving back to build a future that is accessible by default. Thanks for taking on this challenge and happy holidays!
