Making a website more accessible doesn’t usually require a complete rehaul of its code. Instead, code refactoring, which is a process wherein you make adjustments to source code without changing its fundamental external functions, can often be used as a relatively low-effort, low-cost way to improve the usability of a site.
As a technique, refactoring is ideal for improving compliance with WCAG accessibility standards. Consider it less of an overhaul and more of a spring cleaning effort, taking out what doesn’t work, adding in what does, and ultimately ending up with a website that functions more efficiently for users with disabilities.
One area where code refactoring can make a big difference: improving accessibility with screen readers. Individuals with blindness and other visual disabilities use screen readers to navigate the web. And these assistive devices, which rely on HTML code and alternative text to effectively read aloud to users what’s on the screen, won’t work well if the source code isn’t set up correctly.
Below, we’ll go over the process and best practices for refactoring your code and your site architecture to accommodate screen readers. Keep in mind that the goal with any piece of refactored code you input is to improve usability. Making your website accessible for screen readers and those who use them should not mean any sacrifices for other users. Aim for ease of use across the board, and prioritize simple changes whenever possible.
There are two ways to approach the refactoring process: (1) incorporate refactored code directly into the main application; or (2) build a secondary version of the application that can be maintained alongside the main one.
There are benefits and trade-offs to either method. Refactoring code in the main application means saving time, since you don’t have to build a separate interface. However, this requires that you balance out features and functions for both disabled and non-disabled users all in one application — a technique that makes it a bit more difficult to maintain the highest accessibility standards.
Building a secondary interface is preferred for achieving the highest levels of accessibility, since you can completely optimize the version for the needs of disabled users without also having to consider the needs of non-disabled users (which are already taken care of in the primary interface). Of course though, building a secondary version of your code is time intensive, and it’s not always going to be as robust as the primary version, which might not be ideal for end users.
When you’re refactoring for screen readers, your focus is going to be providing and improving access to key information for a select and narrow audience — for example, simplifying busy pages through mergers and splits so they make more sense to non-seeing users. For these purposes, working off the main version of your code should be sufficient.
The Refactoring Process
Begin the refactoring process by honing in on what you want and need to achieve. Keep an eye (or nose) out for “code smells” or “bad smells”— i.e. problems with your code that muddy up your entire site. In the case of improving accessibility for screen readers, your to-do list will likely include:
- Reformatting and/or splitting up busy pages with mixed content that’s not all clearly related
- Simplifying overly long navigation paths
- Optimizing the section layout to eliminate the need for excessive scrolling or otherwise non-intuitive navigation
The easiest way to identify what you need to work on is to attempt to navigate the site yourself using a screen reader so you can get a feel for the experience a blind or otherwise visually disabled user might have. You should also do some dedicated screen reader testing through outside software programs.
As to the screen reader accessibility tasks mentioned above, here’s how you would refactor for each.
Splitting up busy pages: Overly saturated pages can be refactored for better screen reader compatibility by adding content summaries and splitting pages up to distribute information more effectively. Splitting pages is done in design, and generally requires moving content onto new pages and connecting them to the original page with a well-placed link. In addition, look at refactoring techniques centered around organizing data, which will help you eliminate redundant pieces of code and content and simplify the page on both the back and front end.
Simplifying overly long navigation paths: It should be as easy as possible for a user with a visual disability to navigate from point A to point B (or C or D, and so on). To achieve this through refactoring, you’ll want to merge pages and focus dispersed content and operations in order to create a clearer path to various functionalities. Be sure to rename merged pages, as well as the anchor links that lead into them. Try to remove the middle man wherever possible as well so that the flow of navigation is more intuitive.
Optimizing section layout: The best thing you can do to improve your section layout for screen readers is to fix your menu code so that it eliminates the need for excessive scrolling or backtracking on the page. Avoid solution sprawl, too, which is where functionalities are spread out over a number of different classes. To do so, refactor the code so that a function is encapsulated in fewer classes. Any useful functions on a page should be easy to navigate and easy to achieve.
Proficient refactoring will help you get rid of dead or defunct data and remove the barriers to functionality that make pages difficult to navigate with screen readers. Ultimately, you should end up with a site that looks very much the same as it did previously but that is structured with screen reader accessibility in mind.
Go through and do additional testing after the refactoring process to ensure that you’ve met your goals and that the site is truly accommodating to screen reader devices. Even the smallest of code changes can make a big impact, so if you haven’t quite met your mark yet a few additional tweaks might be all that you need.