This is a guest post by Obinna Ekwuno, software engineer at Gatsby and Marcy Sutton, freelance web developer and accessibility specialist. Read more about Obinna and Marcy at the end of this article.

Accessibility has become a buzz word for making sure that disabled users get a fair experience when interfacing with platforms on the web or on mobile. I disagree with this statement. I think putting accessibility into practice shouldn’t be limited to disabled users as that would imply that we would only think about accessibility when dealing with a specific demographic, and that there are cases where we “don’t” need to consider this demographic or it is deemed unimportant.

Now with this in mind I would like to define accessibility as building applications for everyone so that users regardless of their conditions can have equal experiences with the services being provided. A universal approach to accessibility can shift the dynamics of how we implement it in MVPs or even in the founding stages of our applications.

When building MVPs for startups, in the planning phase it is easy to plan a whole application workflow and say “I will do it later” when it comes to implementing accessibility.

Why should I care about this, doesn’t it cost more ?

When trying to make a case for accessibility it can seem like an uphill battle. It is important to note that accessible platforms are usually more user-friendly for everyone and offer a better user experience and in general is a better product than inaccessible platforms. 71% of people with disabilities leave a website immediately if it is not accessible.If you are trying to make a case for accessibility at your company here are a few things to consider:

• Competitive edge: When you have a product that is accessible you will attract a wider audience than an inaccessible platform. More users translates to more value for your work.

• Legal implications: In some cases not having an accessible platform can come off as disruptive as it keeps people with disabilities from accessing essential services. In some countries these people can take legal action towards that company.

• Reach: A more accessible application is more likely to be found on the web and more likely to be used than an inaccessible site.

When factoring in the cost of accessibility, developers often argue that accessibility is just way too much of a cost. Well yes and no.

It does cost money to train your team on accessibility or build native materials like transcripts or translations, but accessibility should never be treated as a feature added later. It should be at the same level of product priority as performance.

Common practice is to add a budget at some point later in the development lifecycle for accessibility (if it ever happens), but it is best to implement accessibility from the beginning of the project as this includes factoring training of staff and actual user testing (if you can’t afford this, automated testing can work but it is advised to test with actual users).

An accessibility production story

In my experience implementing accessibility from the beginning of your development lifecycle can go a long way in increasing the efficiency of your product. t is easier, less expensive and also consumes less time. In the long run it will be beneficial to your business. In the production story of an application, there are a lot of stakeholders. As a result of this, at all levels there is a need to have some accessibility baked into the processes.

Who is involved in the process?

The short answer is everyone – from the user experience researcher to the testers and everyone in between. There is some level of intentional move to ensure that accessibility is incorporated into every part of the product, not just the design and code. While scoping out your product there are a few questions that can help create a sustainable accessibility plan:

• What is the purpose of your product?

• Who are the stakeholders of your product, what are their needs, technology preferences?

• What are the goals that our product helps our users achieve?

• How can accessibility be integrated during production?

• Which target platform, browser, operating systems and assistive technology should we be testing on?

The aim of these questions is to create a document that can stand as a reference for onboarding new members into the team and also something to refer to when making design decisions in the lifecycle of the project.

The process of knowing – Research!

In everything, getting the information first will go a long way in ensuring that you are making informed decisions, in this case with regards to accessibility. In creating a product, doing research can help you gain a better understanding of the people that are going to use the product.

A quick thing to note is that research isn’t just about asking people what they like, it’s figuring out why they like what they like. Understand their habits while keeping them in mind in the process. In an accessibility setting you should focus on users’ needs including impairments and environments. Including users with disabilities in your user research will help your findings hold water. Note that this might prove to be a difficult process but when done right can offer invaluable perspective to your product.

Find and interact with disabled users

The process of learning about your users for accessibility purposes cannot be complete without including actual users living with disabilities. It is important to treat people with disabilities just as you would any other user and not make assumptions about what they need or want. Be respectful with your questions and pay them for their time.

While doing this be careful to focus on users who will actually need the services of your application and not fall into the rabbit hole of taking up data that is not relevant to your application.

Development

Now that you have all this information, after creating your document of execution it all comes down to implementation. Without all this research done accessibility would be thought of as “too big for a feature for an MVP”. Hopefully with all the information gathered you can start from the lower hanging fruits.

When building an MVP your aim is to handle the most important things first and as we have seen, accessibility is pretty important. In creating your application it is important to pay attention to small wins, the basics of accessibility are semantic syntax and also the following:

• Labelling all forms

• Alt attributes on images and text alternatives for icons

• Implementing keyboard accessibility practices by making sure links are links to resources and buttons are buttons that call to action.

By doing these things initially you will have started developing with accessibility in mind.

User land – the good, the bad, how you can help!

As we discussed in the section above we can see that the smallest things can go a long way to solving your accessibility problem. All through this article we have highlighted “user needs”. In this section we will be looking at a typical day in user land. Generally users with disabilities will have vastly different work flows from users without disabilities

Let’s focus on users with disabilities for starters. When it comes to this demographic there are four main area of disabilities that affect the web: visual impairment, auditory impairments, motor impairment, and cognitive impairments

These top areas can further be broken down into specific categories some of which we will look at.

Colour blindness

Say a user had to shop on an ecommerce site, but frequently encounters problems on websites and with apps where the color contrast of text and images is not adequate, and where color alone is used to indicate required fields and sale prices. When you have a combination of red and green without proper description, you have automatically made life hard for this user.

The above user makes up for 1 in 12 men (8%) and 1 in 200 women in the world which is approximately 3 million people.

To support users in this demographic you can ensure that they can adjust the contrast settings of your site in the browser. Also by labelling color names in a section would help provide all the contextual information needed.

Blindness

We have a demographic profile who are totally blind and would have to rely on an assistive technology called a screen reader, which highly relies on structural information on web pages such as headings, column and row headers in tables, list items, links, and form controls. This helps give a mental picture of the webpage.

Seeing as screen readers depend so much on the structure of pages it is important to use semantic syntax when building your platform. Testing your platform with accessibility testing tools like accessibility insights, axe and screen readers gives you a better understanding of how your implementations are executed. If you can get actual information from people that have to use this in real life, that’s even better.

 Motor injury

Sometimes a disability can come as a result of a strain and this can affect how a “non disabled” user who is now temporarily disabled will interface with your platform. How can you support these users?

Keyboard navigation is required by a large demographic of web users and when not present can pose a huge problem as sometimes it is difficult to skip content and navigate to sections on a webpage without using many keyboard commands, which is very tiring and limiting. Implementing proper keyboard support and focus management practices can go a long way in aiding this user.

To go a step further in improving the experience of these types of users, speech-to-text features can also be used as a way of avoiding the need to type on a keyboard.

Auditory impairments

Some users are hard of hearing, although some can hear some sounds but not enough to understand speech. These users rely on sign language for everyday conversations. When it comes to the web and media communications they can only understand what’s going on via captions and transcript. Providing captioning for your media files will help support these users.

Cognitive impairments

A cognitive impairment is when a person has trouble remembering,learning new things, concentrating or making decisions. For example a user can have an attention deficit hyperactivity disorder or dyslexia. Navigating the web can be made easier for such users by using plan language, paragraphs and enabling functionality to optimize line length. This helps the user focus on one word at a time instead of struggling over every word.

Another cognitive impairment that is common is Attention deficit hyperactivity disorder (ADHD) which makes up for 7.2% of the web users. With these users, animations and a lot of graphics can be a huge problem which makes it difficult to get all the information from the platform. Using reduced motion animation in your application can give these users an option to slow down the animations or skip it in general.

Conclusion

In this article we have taken a look at some of the steps that can be taken to make sure your MVP places accessibility at the heart of its development and gets the small wins into your app at the beginning of the process. We have also taken a look at how to utilize the research process and including actual user needs in this process. I hope to see some of these improvements in how start ups scale processes. Happy coding and let’s make a web for everyone!

About the authors

Marcy Sutton is a freelance web developer and accessibility specialist. Previously, she’s worked as the Head of Learning at Gatsby and on the open source axe-core accessibility testing library. In 2016, O’Reilly gave Marcy a Web Platform Award for her work in accessibility. She’s a founding member of the Accessibility Seattle Foundation, a nonprofit supporting the A11ySea meetup. When away from the keyboard, Marcy can be found hiking with her dog, riding a bicycle, or snowboarding.

Obinna Ekwuno is a Software Engineer with a passion for teaching currently working on the DevRel team at Gatsby, he is also a Cloudinary Media Developer Expert and writes about a lot of exciting stuff on Scotch.io and logRocket some of which include topics around JavaScript, Jamstack and the MERN stack. He is mostly nerding out about web accessibility and web performance.