In the current age of web development, we tend to focus on the next big thing we want to deploy to our site. We’ve all been captivated by the newest flashy design, or the choice to update to an entirely new JavaScript framework such as React or Angular. It’s always about moving forward to the next thing to stay relevant and up-to-date. But what often gets left behind in this process are legacy applications.
Every site has some legacy content that exists within it. It may be a few pages that haven’t been touched in a long time, a codebase that hasn’t been updated, or even an entire application flow that worked great at one time but has never received an update. In many cases, the teams that developed the content or have knowledge of how the code base works may have moved on.
Site owners tend to forget about this legacy content because it’s been in place for so long or because it predates them. However, this content is still a part of your site as a whole and still needs to be accessible for all to use. Luckily, there are a few key ways to test and then remediate those issues, to make sure that legacy content on your website or application is accessible.
Testing Legacy Content
Keyboard Test
Keyboard navigation is one of the most important aspects of accessibility. Keyboard users have certain expectations and assumptions for what will happen when they tab onto a button, click into a form field, or select an item from a combo box. Keyboard testing ensures that not only can a user interact and navigate the page with the keyboard, but also that a user can do so in a predictable way.
Most of us know that the tab key and arrow keys will move through the page links and form controls, shift + tab steps us backward, and enter (and sometimes spacebar) can be used to select an element. There are other controls to keep in mind when developing too, such as tab panels, accordions, and carousel navigation.
Keyboard testing can also help with the detection of keyboard traps. A keyboard trap is just how it sounds: when a user becomes stuck on one element, unable to move to other actionable elements on the page. This is highly problematic for keyboard-only users and can be largely avoided if keyboard testing is performed during remediation.
Tip: Always check Deque’s Custom Widgets if you have any doubts about how your content should work with a keyboard.
Ensure No Positive Tab Indexes
As a rule, tab indexes should never be set to a positive number. Legacy applications are often the biggest perpetrators of breaking this rule. Anything one or greater will begin to define an explicit tab order that interrupts that natural tab order of the page. Elements with a positive tab index will always receive focus before other elements on that page that are actionable or have a tabindex=”0”.
Example of positive tab indexes. In this example ‘Sign in’ would receive tab focus first, followed by ‘Forgot Username then ‘Forgot Password’, and finally ‘Remember Me’:
<div class="container">
<div>
<input type="checkbox" id="remember"/>
<label for="remember">Remember Me</label>
</div>
<button tabindex="1" class="btn">Sign in</button>
<a href="#" tabindex="2">Forgot Username?></a>
<a href="#" tabindex="3">Forgot Password?</a>
</div>
When it comes to remediating legacy code that uses positive tab indexes, this is perhaps the biggest undertaking of the issues we’ve listed here because it could potentially require a major refactor of the code base, which extends far beyond replacing positive tab indexes with 0.
In short, ensure that HTML tags do not have tab index set to greater than 0 and be sure there are no scripts adding positive tab indexes to your content.
Use an Automatic Scanning Tool
Use an automatic scanning tool such as the axe extension to test your content for accessibility issues. The axe accessibility checker for Chrome and Firefox is a fast, lightweight accessibility testing tool that returns zero false positives. Axe allows you to get the accessibility violations of your content in just the push of a button! And it’s free!
Automation does not catch all the accessibility violations that exist on your content and does not replace the first two items in this list, but it can help you quickly scan pages for accessibility violations and create a list of violations to work from and fix to make your legacy content more accessible than before.
Remediation
Use ARIA Where Possible (But Only If Used Properly)
ARIA stands for “accessible rich internet applications” and helps make web content or web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. With WAI-ARIA, developers can make advanced Web applications accessible and usable to people with disabilities.
In the accessibility community, the number one rule of ARIA is, “Don’t use ARIA.” This rule is in place because most developers use ARIA incorrectly, which in turn makes websites even more inaccessible. However, sometimes there isn’t enough time or knowledge to refactor the codebase into semantic HTML. Other situations might require massive changes to CSS and possibly the JavaScript as well. This is when ARIA comes in handy.
Example usage of ARIA in a legacy application:
<div class="main-content" role="main">
<span class="h1" role="heading" aria-level="1">Welcome to our site!</span>
<div class="container">
<p>Please enter your information</p>
<input type="checkbox" aria-labelledby="checkLabel" value="a11y">
<span id="checkLabel">I like accessibility</span>
<div tabindex="0" role ="button" class="btn">Continue</div>
</div>
</div>
ARIA is a set of attributes that define ways to make web content and web applications accessible in a quick and orderly fashion. It does not require major changes to the HTML elements, and it allows for simple changes to each specific HTML tag to make it accessible. Although this does technically “break the rule of ARIA,” when it comes to legacy applications, ARIA can be a great way to quickly make content accessible without making a large impact on the codebase.
Create An Accessibility JavaScript File
It can be helpful to distinguish between JavaScript that maintains the core functionality of your application and JavaScript for accessibility. In this case, we are talking about creating a JavaScript file that will fix all (or most) of the accessibility issues on your legacy application. This technique allows you to change content without touching the legacy code, and since it usually does not change drastically over time, the opportunity to make accessible changes via Javascript is possible.
Similar to the scenario above, if you do not have access to the change the legacy code, the code is from a third-party library or created by a third party, or you cannot change semantic HTML, or flat out do not have the knowledge of the code base, creating an accessible JavaScript file can help. In this case, a developer would find all the accessibility issues on their site, and instead of going into the codebase to fix them, they would simply fix all of them with JavaScript and add the script to the application itself. Then, when the page loads, the code is applied to the page itself and the application will then be accessible!
Here is a quick JavaScript snippet that would take a non-semantic button, and add ARIA and add keyboard events to it.
const contButton = document.querySelector("#continue");
if (contButton) {
contButton.setAttribute("tabindex","0");
contButton.setAttribute("role","button");
contButton.addEventListener("keydown", event => {
if (event.code === "Enter" || event.code === "Space") {
event.preventDefault();
event.target.click();
}
});
}
Deque offers a service for creating this accessibility JavaScript file and even CSS fixes as well, called Amaze, contact us if you’d like to learn more.
Learn the Codebase
When in doubt, learn the code base and adapt. If the legacy code you support is used abundantly within your organization, then the best approach may not be a quick fix like the above two items. It may be best to learn the code base and make the changes at the source level.
Although it can be easier to use ARIA or create a JavaScript file for accessibility issues, sometimes the good old fashioned way of just learning the code base works best. These changes could include not using ARIA and changing content to semantic HTML. Fixing the accessibility issues at its source can be the best way to ensure accessibility is there forever.
In Summary
While at a certain time, legacy applications may have been a modern and steady solution, over time they can become inaccessible as other code takes priority. Even though the code creators or maintainers may be long gone and the overall understanding may not be there, ultimately, you are responsible for the content that is presented to the user in these applications.
Using the testing strategies above to find your accessibility issues, creating a plan of action to fix them, and then remediating them with one the strategies suggested will help create a unified experience in your new and legacy content that will help ensure that your content is usable for all.