I’ve been focusing on web accessibility for a few years now. One of the complaints I’ve often heard from business owners and managers is that implementing accessibility is hard and slows down the development process. For this reason, sometimes accessibility gets postponed or set aside in the erroneous belief that’s something that can be “added” later. Here, I’d like to share my thoughts on why I think the first statement is misleading. I’ll also discuss why postponing accessibility is an ineffective process that can add a considerable amount of time to your development process.
Everything slows down development
I’ve often heard statements like “accessibility slows down our project as a whole,” that’s not new to me. Managers who would like to see speed of iteration in their project often think that they can postpone some requirements when quickly developing a particular feature is worth it. Put this way, this statement sounds very questionable to me. Is accessibility the real reason why a project slows down or maybe it’s about something else?
Imagine one of the technologies used in your project is PHP and your development team knows very little about PHP. Would you say “PHP is slowing down my project”? Certainly not. In this case, it is clear to everyone the real problem is the lack of expertise. The obvious solution is training your team. Continuous education as a means of speeding up the development process.
Of course, this applies to any technology and best practice, including web accessibility. Expanding our manager’s misleading statement, we could then say that any particular technology or best practice slows down the development process. That doesn’t sound right, isn’t it? As always, it’s more a matter of education, knowledge, priorities, and decisional processes.
A simple code example
You can implement web accessibility at different levels. Some things are very simple; others are a bit more complex. To make things more clear to people used to reasoning in terms of code, let’s do a very simple example. Imagine you have to build a user interface control that’s a button with an icon and no visible text. In pseudo-code, that might be something like this:
This example is not accessible because there’s no text assistive technologies can announce. In technical terms, there’s no “accessible name”. Screen readers read out the button just as “Button”. This way, users wouldn’t have any clue what it does.
Although this is a straightforward example, I’ve seen things like this happen several times in the same project. When coding, mistakes and bugs are expected. No one is perfect, just because we’re human. However, when similar mistakes happen again and again, that’s a clear sign of lack of knowledge. That’s the real reason why your project may slow down.
In our example, one of the simplest ways to improve a bit accessibility is adding some text within the button (even some visually hidden text). We could also add an aria-label attribute. For example:
Further improvements are certainly possible. The purpose of this example, however, is to highlight how accessibility is very simple sometimes. It is very fast to implement. How much development time would be necessary to add that aria-label attribute? Even if you’re not a coder, I think you’d agree it’s just a matter of seconds. Can this slow down the development process? Certainly not.
Invest in education
Of course, sometimes accessibility is a bit more complex than our example above. Dynamic, modern, web interfaces based on advanced “widgets” require more knowledge and more advanced accessibility solutions. By the way, they also require more advanced PHP (or any other language) knowledge, more JavaScript knowledge, and so on. How is this different from having more accessibility knowledge?
When accessibility is a project requirement, the best option our managers have is to invest in their team education and increase their expertise. If you integrate accessibility into the development process, it becomes a coding routine. Development time won’t increase so much if developers in your team already know what to do.
In modern web development, reusable user interface components also offer an excellent opportunity to integrate accessibility since the beginning. Once a developer finishes a component and it provides a good level of built-in accessibility, it’s done forever.
Accessibility is design
Web accessibility is mostly about building well structured, rich, semantic HTML For “HTML,” I mean the rendered one, whether it’s produced with server-side scripting or a JavaScript framework or anything else. To produce well-structured markup, there’s the need to design it. This should happen even before designing the presentation layer (the “visual design”). In addition, you should integrate it early in an inclusive design process.
Think of a web page as a “document”. People with different abilities consume these documents. They often use different types of software to read the document source, so you must build the page content in a meaningful way. You should make the order of the main sections clear, it should facilitate navigation through content. It should also make it easy to get an overall sense of the document. Group user interface controls logically and place them where it makes the most sense, where they are easily and intuitively found. Any interaction on a web page should be what users expect to happen based on the provided information. Give feedback after any action. And so on, and on.
This whole process is actually a design process.
It’s about designing the information architecture. In my experience, and you can ask any person with some accessibility experience, I bet they will give you the same answer, this process must happen at the beginning of the development process to be effective.
Iteration
Modern web development is often based on a quick iteration process. The development cycle is all about delivering fast and iterating often. That doesn’t mean you should set aside web accessibility. Instead, follow the same iteration process and integrate it into the development cycle from the beginning.
Managers who think accessibility can happen at a later stage don’t realize that’s often too late. When important technical decisions have already been made, when the presentation layer has already been defined and the chances to introduce relevant changes are minimal, then implementing accessibility becomes an ineffective process that may achieve technical compliance but with a compromised user experience. It’s just too hard and too time-consuming changing fundamental technical decisions that have already been made. In this case, I’d agree retrofitting accessibility is costly.
At that stage in the development cycle, and in the best case, all you can pragmatically do is trying to “patch” here and there, in the hope to reduce the most severe accessibility barriers. That’s a very ineffective way to implement accessibility. In the same exact way, it would be extremely ineffective to introduce new coding patterns at the last stage of the development cycle and refactor all the previous work.
Where to start
Start with education. Accessibility is a process: there will never be a time when a web application is “100% accessible”. Instead, it’s more about a continuous improvements workflow, based on testing, changing abilities, and new users needs. Investing in education it’s the only way to achieve good results in the long term, with any technology, and with web accessibility as well.
At Yoast, accessibility matters a great deal. We know it’s a process and we’re continuously improving, testing, iterating, and developing. We’re always open to feedback and contributions. Please do not hesitate to let us hear your voice. Please report any issues or potential improvements you notice in our products.
11 September 2024
Learn how to start your SEO journey the right way with our free webinar. Get practical tips and answers to all your questions in the live Q&A!
All Yoast SEO webinars »
1 Response to a11y Monthly: Does Accessibility slow down development?
1 Response to a11y Monthly: Does Accessibility slow down development?