When building websites, there’s a perception that accessibility is difficult and expensive to get right. When you’re building towards a Minimum Viable Product (MVP), things that seem difficult and expensive are likely to be deprioritized. Don’t fall for this trap! If your MVP isn’t accessible, then is it really viable? And going back to retrofit accessibility into an inaccessible product is always going to take more work and cost more than getting it right the first time.
So how can we account for accessibility when working on an MVP? To borrow a phrase, “an ounce of prevention is worth a pound of cure.”
Consider accessibility from the start
If you pay attention to accessibility experts, you’ll hear the phrase “shift left” quite a bit, but what does that mean? Simply put, it means that the earlier in the process that you think about accessibility, the better. Most products are built following a linear or iterative process like the following:
If you haven’t thought about accessibility until you get to testing, or even worse, after deployment, that’s a big problem. To fix issues, you have to go back to the earlier steps to fix those mistakes. However, if you’re thinking about accessibility from the very beginning, you can avoid making mistakes that would require that sort of rework.
For example, imagine you’re building a to-do list, and a primary interaction is to swipe an item to the right in order to mark it complete. Once this gets to the testing phase, you realize that there’s no way to mark an item complete if you’re only using a keyboard. Uh oh! Now you need to go back to design to figure out an alternative mechanism that then needs to be developed and tested again.
As a counter example, imagine this scenario if the design had accounted for keyboard-only users from the start. Most likely, the swipe interaction would be discarded in favor of checkboxes, which can be used with the majority of assistive technologies. Which brings me to my next point.
Keep it simple
Most of the time when accessibility issues are introduced, it’s because we’re trying to be fancy or work against the grain of the web platform. It turns out you can get pretty far by using semantic HTML with a little CSS. The web is mostly links, forms, text, and images. If you can achieve your product’s goals with just those, you can avoid a lot of self-imposed headaches.
Consider the Mega Menu. These are components that are used to hide potentially dozens of links, and those links sometimes include nested menus and other interactive content. In other words, they’re a nightmare to develop, let alone in an accessible way. Do Mega Menus need to be this complex, though? Is it the best user experience to make clicking on or hovering over a menu item reveal this behemoth of an interface? I think not.
Instead, the contents of the mega menu could be set up as a standalone page. You click on the top-level link in the header, and it navigates to the page with all the links and content related to that topic. Even if it is just a page that’s a list of links, that’s fine. It’s more accessible and it requires far less work to build. As it turns out, progressive enhancement and accessibility go hand-in-hand pretty well.
This is just one example, but there are many design patterns like this that can be replaced by alternate approaches that are easier to implement and more accessible by default. So how can we figure out what those alternative approaches should be?
Developers and designers should talk to each other
In a lot of teams, the hand-off from designers to developers can best be described as “throwing it over the wall.” The design is “done” and developers are meant to implement it to the best of their abilities. This doesn’t work, though. Even in the most well-thought designs, there will be gaps, like, “at which point should this three-column grid change to two columns or one column?”
In a completely siloed team, it might be the developer who makes the call. In a slightly more cooperative team, the developer might ask for clarification for these types of one-off cases. In an ideal workflow, designers and developers are constantly working together and reviewing designs and implementations on a regular basis. Instead of throwing it over the wall, you’re playing hot potato, quickly passing things back and forth and making sure nothing gets dropped.
This collaborative workflow is critical when it comes to accessibility and MVPs. Both parties have the same goal, which is to build the most accessible product as quickly as possible. However, designers may not know the details of how to make a design pattern meet development accessibility guidelines or how difficult it is to do so. The things that are easy seem hard and vice versa.
If a developer is involved when designers are working on initial ideas, they can chime in when something that’s likely to take a lot of effort to make accessible is proposed. Then the designer and developer can work together to figure out alternative approaches. The end result should end up easier (and faster) to implement, and it should be less prone to accessibility issues.
Likewise, a designer can provide annotations for things that developers might not consider, such as what the accessible name should be for an icon-only link or what the alternative text should be for a hero image. Designers can also indicate heading levels so that developers use the correct heading tags (h1-h6) instead of applying the font sizes and weights to p tags. Designers can also note accessible color combinations, target sizes for small links/buttons, reading order, and so on and so forth. The point is that developers and designers can use their expertise to teach each other while building the most accessible version of the MVP that they can.
Note that it helps if both the designer and developer have a good understanding of accessibility to start with. At Sparkbox, we have a number of certified experts who take on the role of accessibility lead for different engagements, where they review designs and code to make sure there aren’t any glaring accessibility issues. They don’t always have the time to review every wireframe or pull request, though, so what else can be done to bake accessibility into the process?
Include accessibility when writing requirements
When writing a Jira ticket, GitHub Issue, etc. to describe work to be done, there are usually “acceptance criteria” or a “definition of done” that tell you what needs to be true in order for that unit of work to be considered finished. For development tasks, these might include things like “all unit tests pass” or “there are no visual regressions” as well as items related to the feature in question.
In addition to those criteria, the following can be added to check for basic accessibility issues that could come up, regardless of what you’re working on, such as the following:
Automated accessibility checks don’t surface any new issues
All content can be operated by using only the keyboard
All images have good alt text or use
alt=““if they are decorativeElements using ARIA roles and attributes use them correctly (ask an expert to review)
This doesn’t cover everything, but it will help catch most accessibility issues without adding too much burden to developers. Even the bullet point about ARIA is helpful for non-experts because it will prompt them to look up ARIA if they don’t know what it is, and it will call attention to anything that isn’t built with good old fashioned semantic elements.
This also bakes basic accessibility testing into the development process, helping prevent easily detected problems from making their way in front of users, either at launch or in user testing. If pull requests are appropriately sized, the amount of testing required should be relatively small for each pull request. If you have a continuous integration process, you can even set up a step to run automated accessibility checks.
Accessibility is nuanced, though, so some accessibility issues may still get through to production. However, if you have a process like this in place, that goes a long way toward proving that you take accessibility seriously. That can lead to you just having to fix the issue instead of going through a lawsuit and facing fines or penalties.
Building with accessibility in mind saves time and money
By thinking about accessibility earlier in the process, you can avoid making costly mistakes and bad decisions. By having developers and designers work closely together, you can design interfaces that are more accessible by default and easier to implement. By requiring that accessibility be tested during the development process, you can prevent inaccessible products from getting in front of users and avoid the costs of potential lawsuits and re-work.
Rather than paying lip service to accessibility (or ignoring it completely) while working toward an MVP, accessibility should be a driving factor that guides product development. It makes your MVP more viable, and it reduces the time and effort required to get that minimum version ready for launch.
