In this article

Accessibility should not be sidelined as a mere add-on. It must be an integral part of development from the start, requiring the inclusion of disabled individuals to ensure the product meets a diverse range of needs. Integrating accessibility features late in the development process, especially for custom JavaScript widgets, leads to costly redesigns. This is avoidable by addressing accessibility from the outset using accessibility first mindset.

Table of Content

Everyone working on web development has heard and utilized the term “mobile first” which means to design the mobile layout first and iterate the design and layout from there to larger screen widths. Mobile-first design is also known as responsive web design.

Before responsive design, it was thought that the mobile version was just a secondary version – and oftentimes the mobile version of the page was available at m. or m-dots subdomains as a standalone application. This was until it was apparent that the majority of the traffic was generated by users using a mobile device, which led to the new mantra – mobile-first design. This led to the mobile design being the primary design and the basis for the desktop design.

Likewise, accessibility is not something you can just implement to the project once it is done – it’s no plugin or addon. Accessibility requires constant attention during the development process. Involving disabled individuals throughout the design process is needed to ensure that their needs are understood and accommodated.

Do it right or do it twice

When developing web pages, especially those with custom JavaScript widgets such accessibility features must be implemented right away. If the accessibility features are omitted in the beginning thinking that they can be added later on you are making a big mistake. In many cases, it might be too late to add the accessibility features once the widget is finished. In the worst case, you might need to redesign the whole widget with the accessibility features in mind costing you at least double the time – rather than just “biting” the bullet once.

If you need convincing as to why you should even consider accessibility: accessibility also bears many additional benefits, which I have described as the side effect of accessibility. Some of the side effects include improved search engine optimization (SEO), enhanced usability, better customer satisfaction, grown market reach, and strong brand reputation – these all lead to better ROI for the business.

Accessibility first mindset

The idea of accessibility first – like with mobile-first – is to implement one version that is usable by the most amount of people using the most variety of different user agents.

This could be easily done by simply involving accessibility features from the get-go. Involve accessibility teams, experts, and also individuals with disabilities as early as possible. Otherwise, you are probably wasting time and prolonging the inevitable. You would not publish a web page that is not responsive, so why would you publish a version that is not usable by a screen reader?

Blindly following the WCAG guidelines will get you only so far. It’s not 100% guaranteed that conforming to every success criterion will lead to a fully accessible website. This is why it is mandatory to test, test, and test. Like I said – involve real users to get the most accurate feedback and understand the flow of interaction. It is also beneficial to involve different individuals with different types of disabilities to get the best outcome.

Of course, as in anything, there are corner cases in disabilities also, but if you manage to cover the needs of 95% of individuals from the start it can be iterated when problems arise for the rest.

Maintain long-term accessibility

Once the website is published the accessibility-first mindset does not go anywhere. The mindset must be taken into the continuous delivery practices. Every new feature must be developed using the same principle. Treating accessibility as a one-time project and failing to integrate accessibility into the workflow will lead to accessibility rot.

Accessibility rot

When accessibility is not a constant design principle, the whole system will start to rot. Small accessibility errors will creep into the codebase eventually rotting the whole service making the service non-accessible and ultimately making the accessibility efforts useless.