Developers will joke that in some older websites and apps, what looks beautiful to the user is built on code that looks like a demolition site. Most long-standing websites or apps are built upon layers and layers of code — the oldest we like to call “dinosaur code.”
As companies implement updates to make products more accessible, it’s not uncommon to run into legacy code issues that make these necessary changes much more challenging than expected. Correcting websites and apps requires sifting through several layers to discover and fix every problem.
With all the challenges business leaders juggle, keeping older product infrastructure up with accessibility standards can be one of the most challenging. Because of the large amounts of legacy code and the complexity of WCAG standards, there’s a misconception that these improvements are expensive and time-consuming.
That’s not necessarily the case.
As you start, however, you may have to dig deep into the code to uncover necessary changes.
Accessibility basics: the benefit of digging.
According to The Centers for Disease Control and Prevention, one out of four adults in the U.S. has a disability, including deafness or severe difficulty hearing (5.9%) and blindness or difficulty seeing (4.6%). Organizations actively monitor and update their websites to comply with American Disabilities Act (ADA) standards, which are usually measured by the Web Accessibility Content Guidelines (WCAG). In 2021, WCAG failures were detected on 97% of company homepages.
There’s a business case for making digital platforms accessible, too. In the U.S., making content accessible expands your potential customers by up to 19 million people. These updates will help reach more people, give your customers a higher quality digital experience, and positively benefit your SEO efforts.
Typical layers of website development
Digging through layers to find and remediate your “dinosaur code.” Imagine you dig through the earth’s crust in the right place; you may eventually reach a layer that’s hiding a prehistoric fossil that gives you something to learn from.
- Recent ad-hoc updates like alerts, promotions and CMS content changes
- Rounds of bug fixes and enhancements
- Third-party code added to the site
- Newest redesign/refactors
- Other redesigns/refactors
- Initial redesign/refactors
- Original semantic HTML
The deepest layers on older websites are also where you’ll find some “prehistoric” code. Sometimes these layers may be reasonably accessible because the developers used semantic HTML to create the content. The next layer up—early redesigns—may be the least accessible because designers and developers will sometimes stray from conventional usability and digital experience best practices to add visual flourishes and complicated features that can be confusing or unusable to some users with disabilities. The most recent layer of code is likely to be more accessible because developers have leveraged modern code libraries, which have more accessibility built-in.
Assembling the dinosaur: minimizing accessibility costs through “triage.”
At Nerdery, we aim to minimize cost while focusing on areas with the greatest impact on users. We look for the root causes of accessibility issues and identify correlations or similar problems. For instance, adding alt tags to charts and diagrams or including correct link descriptions will immediately improve accessibility yet require comparatively little time and expense.
As you audit your site or application, prioritize what needs addressing now and which elements could wait until later. You can approach the work in phases, making iterative fixes and improvements.
Consider addressing global issues first, affecting the most number of pages with a single code change and potentially reducing your legal risk in automated scans. Alternatively, you can start with identifying issues based on business priorities, budget available, timeline, impact on site traffic, and future site or app enhancements.
From there, separate the technical violations, the confusing experiences (for example, random keyboard tab order, missing page headings, and poorly labeled links), and bugs that completely block functionality for some users.
The key is good experience first, requirements second.
Use this tenet to help you prioritize the task list in your overall code project plan. Instead of focusing on the WCAG level of severity, think about how each issue will impact a variety of different users and assistive technology. Examine customer support calls and chat histories for issues that affect users with disabilities. Armed with data, you can begin to create a constantly changing but actionable to-do list.