A few months back, Aaron wrote about the high-level aspects of Accessibility-First Programming, its importance, and specific strategies and tools for applying it within your software development process. It included insights and suggestions for Color and Contrast, Focus Management, the use of ARIA tags and attributes, and testing strategies and tools – all of which are important things to consider. 

In this post, we’re going to dig in a little deeper on three of those topics that I used on my last project: ARIA, the WCAG and what is needed for compliance, and some design principles of accessible design. We’ll include insights and further reading on relevant topics to help you better understand how to implement accessibility-first programming in your own development.

When you think of common programming techniques and processes, what comes to mind first? Perhaps it’s test-driven development, writing an automated test to start your development cycle and putting testing at the forefront instead of the typical afterthought. Or maybe you thought of behavior driven development with stakeholders collaborating and defining the software behavior upfront thus mitigating the ambiguities from some requirements. But what if I told you that while testing and behavior are important, accessibility should be one of the first development considerations?

Maybe the whole concept of accessibility is nothing new to you, and you’re already accounting for it in all aspects of the development process. But, if you’re like most developers (myself occasionally included), accessibility along with unit testing are the two things you often save to the very, very, very end, or perhaps you save them for the newbies to worry about in a future sprint – neither of which is ideal. While it may not be quite as important in some industries as it is in others like government (where Section 508 is federal law regarding accessibility), addressing it should be in the forefront of your thought process, your code, and your testing.