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. That’s great. 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.
In this blog, we discuss the importance of accessibility-first programming. We then share specific strategies and tools for applying accessibility within your daily software development processes.
According to a fact sheet from Laser Eye Surgery, 2.2 billion people live with some form or another of vision impairment. Just think about that for a minute, 2.2 billion. It’s really quite staggering. But this is just one statistic and only one of many factors relating to your potential users. There are numerous considerations that may impact your users: other physical limitations that may also affect the use of a mouse or keyboard, ability to read, primary language – to name a few.
With the prevalent use of the internet within our daily lives and the ever-increasing variety of devices, this all greatly magnifies the criticality of accessibility. By making your application accessible, you are also addressing major aspects of usability. The two are greatly intertwined. And the whole goal is to make information usable and available to anyone and everyone – period.
So how do you go about achieving this nirvana of accessibility? I’m glad you asked.
(Yes, I’m an Apple fanatic, but the thought of the slogan really applies well.)
Accessibility-first development takes a shift in mindset and perspective. You have to look at things from a different viewpoint. Just because something makes sense to you, and the code and browser lets you do it, it doesn’t mean that it will make sense to everyone nor that it’s the right choice. (Whoever thought that it was acceptable to have blinking HTML tags…?)
We can see a perfect example of this change in thought process with something as simple as an address label. When you want to display an address on a screen, you typically think of the common structure we’ve all seen on an envelope – each part of the address on its own individual line. For example:
1640 Riverside Drive
Hill Valley, California 95420
The problem with this layout is that a screen reader will just read through it like a blob of text with no meaningful context. (A screen reader is an assistive technology tool that can present the content on the screen in a variety of non-visual formats.) The appearance of the address is acceptable, and there are no code limitations with the structure. But regardless of how commonplace this layout may be and how “normal” we may view it, the result isn’t always useful for the user.
So, what would be more accessible?
One simple option would be to utilize a table structure, supplying column or row headers with each line. Then when the screen reader announces the information, it will supply the context of the data using the headers. It goes from being that blob of ambiguous information to something meaningful with just a little bit of perspective, thinking, and inclusive coding.
Screen reading tools are extremely useful in assisting with this paradigm shift. What better way to change your thinking than to experience it first-hand. More on this later.
Context is Key
Coding for accessibility isn’t really all that difficult. In fact, a lot of frameworks handle most of the heavy lifting for you right out-of-the-box, or they at least supply the mechanisms to make it simpler. Angular is particularly helpful in this sense. They even have an entire package, a11y, devoted to accessibility within their material design library.
Despite all of the features built-in to the frameworks, there are still a few things in particular that you, as a developer, should be aware of and have in the forefront of your mind. Let’s skim the surface and walk through a couple of them.
Color and Contrast
This area is likely one of the more obvious and one that people think of most when considering accessibility, but it is also an easy one to both mess up yet also correct. Using certain color combinations will greatly impact the usability of your application. We’ve all likely and unfortunately seen some not-so-good examples of this like yellow text on a white background which renders it completely unreadable and consequently unusable. Your users may be further impacted by your color choices if they have a visual impairment like color blindness.
Fortunately, the Web Content Accessibility Guidelines (WCAG) 2 produced by the World Wide Web Consortium (W3C) provides several standards on the ratio for color to contrast for content to its background. There are also many tools that will provide recommended color palettes as well as test your site against the WCAG recommendations. It won’t prevent you from picking the not-so-appealing colors, that’s still up to you, but will at least help you in keeping the contrast at the appropriate level.
This may be a little less obvious than color and contrast, but focus management is particularly important with a single page application (SPA) due to the nature of how they work and how the content is displayed. With a SPA, there aren’t the typical page transitions that traditional sites have, so you have to be more intentional with the user’s focus.
As a user of the system, I must be able to perceive how the view has changed and that the user agent directs my attention appropriately. For instance, if your user is interacting with a list of results on a SPA and paging using a pagination control, the next set of data may be repainted with no direct notification of a page change.
Typically, the paging control is towards the bottom of the list and may not be in the same direct line of sight as the beginning of the list. So, when they click to the next page of information, if you leave them focused on the bottom of that list with the pagination control, they will have lost context of that next set of data. Rather, it’s best to place the focus back to the top of the table listing so as to provide context again.
Another aspect of focus management is the concept of keyboard trapping, preventing the user from tabbing outside a specific region. This is particularly useful when presenting a modal dialog on a screen. You want to contain the user to the dialog and not have them tabbing through other areas behind the dialog, losing context. Angular has built-in directives in the a11y package like cdkTrapFocus and cdkFocusInitial to help handle all of these scenarios.
One other important part to focus management is that you want to return the user to where they started. If they clicked a button to launch a dialog, for example, you would want to set focus back to the same button when the dialog closes. It’s once again about providing the user with context. If you’re using the Angular Material components, a lot of this is addressed and available to you inherently. However, if you’re not utilizing Angular Material within an Angular project, you’ll have to manage this more directly within your code, keeping track of the originating element and such.
Focus management doesn’t just address accessibility, it also improves overall usability for your application. As your user tabs through the page, you don’t want to leave them thinking the lyrics of Cotton Eye Joe – “where did you come from, where did you go”.
Using The Right Tool For The Right Job
When you’re writing the HTML, you need to ensure that you’re using the appropriate tags and applying the correct attributes. ARIA (Accessible Rich Internet Applications) attributes are very critical to making your content accessible. The attributes help to describe your elements and inform the screen readers about what it all means and what to do with it. This is why it’s important to use the right one at the right time. If you don’t supply ARIA attributes or provide the wrong ones, then the screen reader won’t be able to present the content in a meaningful fashion.
This concept also applies to which tags to use. For instance, while buttons and links can be used interchangeably to a great degree and can be styled to look like each other via the power of CSS, each one has a specific purpose. Buttons should be utilized for a user action, including such things as submitting or clearing a form, launching a dialog, etc. A link, on the other hand, should be used strictly for navigation, when the user is being redirected to a different URL or a different route in the case of a SPA. Where this use case gets a tad muddled is in the case of a navigation menu. Menu items that just open a sub-menu list should be buttons, but if the menu items themselves are navigable, they should be links. Simple, right?
Test Early And Often
As I mentioned at the beginning, testing along with accessibility is typically one of those last things you worry about during development, if at all. So, it’s even better if you account for both early and often. Fortunately, there are many tools to help in this endeavor. This could easily be another blog post or two in and of itself, so I’ll just hit some quick highlights to get you on the right path.
Deque Labs created an accessibility engine called axe-core which is used as the accessibility brains for many tools and can also be utilized directly for unit testing. They have provided several examples within their GitHub project that demonstrate usages within various testing frameworks like Jest, Jasmine, and Mocha. While unit testing for accessibility won’t catch everything, it will at least help in address some common aspects like color and contrast and the use of aria attributes.
Google’s Lighthouse tool is a great development tool to test a variety of aspects within your application including accessibility as well as performance, best practices, etc. It actually uses axe-core under the covers to handle the accessibility audit feature.
Another must-have for developers is a screen reader. What better way to test an application than to experience it in the same manner as your users! JAWS is probably the most widely known screen reader and has been around for quite some time. NVDA by NV Access is a great open sourced option for Windows and one that I’ve personally used for testing applications.
More tools continue to become available as companies address the need for accessibility. Some of those tools are more feature-reach, work on specific operating systems, require licenses and therefore cost, etc., so be sure to pick what best addresses the need and that of your users. Ultimately, direct user testing utilizing screen readers is the most effective way to verify accessibility.
After reading through all of this, my hope is that I’ve helped you see the need for and importance of accessibility-first programming. Hopefully, this gets you to begin thinking of how to apply accessibility within your daily software development process.
As with everything in the realm of software, it’s a continuous never-ending cycle of learning, implementing, and improving. The earlier and more often we account for accessibility, the better – in time estimates, requirements, coding, testing, etc. And in the end, you’re providing a better user experience for everyone.
Accessibility, that’s what’s on first!