Freeing Backbone from freemium – Simplicity as an accessibility feature
In an era of free website builders and AI-generated content, it seems backward to propose creating a modern website in plain HTML. But it’s an effective strategy that has a special place in our hearts.
Backbone came to us because their WordPress site was hard to maintain and was tangled up in multiple third-party plugins. They were also especially concerned about their site’s accessibility and wanted us make improvements. Our first step was to run their site through WebAIM’s WAVE tool. Even though their WAVE score was a better-than-average 8.3/10, we identified several serious accessibility issues.
In particular, the site was hard for computers to read, which meant screen readers and keyboard navigation didn’t work well and their search engine optimization (SEO) was harmed.
This is what their footer looked like visually – seemingly quite clean and understandable:
But compare that to what a computer saw:
On the far left is a birds-eye view of the structure; this is what it would look like to “tab” through the page without a mouse or vision. It’s also part of what a search engine like Google would see when trying to understand whether your site is relevant to a search term. It’s a mess.
On the middle left is the analysis from the WAVE tool highlighting several severe errors. Screen readers can barely work, and keyboard navigation is almost entirely broken! This wasn’t Backbone’s fault (their site started much better than average because this is something they care about), but it’s the sad status-quo of free web builders.
New beginnings
Now here’s the same footer after our changes. Visually, it looks very similar:
But you can clearly see the improvement in the computer overview of the page:
Look specifically at the red-circled “go/contact” button before and after: it started as unlabeled element 58 like an unimportant side character in a movie, but after our changes it’s been elevated to button 5: contact which actually explains what users can expect when clicking on it.
When we intentionally restructured the page, we were able to completely transform how this website looks to screen readers and to search engines. A human merely had to decide “is this a sub-section, or is it a new section?” and code the HTML accordingly.
But what did users think?
These results look great to the automated tool, but professionals in the space will know that this is only part of the picture. Luckily, we know our work translated to a real increase in accessibility, not just against the automated tests. Backbone conducted a series of user studies to validate the new site, and users clearly preferred the improvements. Even more importantly, our client was able to take what we delivered and continue making changes to it without us!
It’s worth reiterating that this site has NO plugins and it still looks fantastic to search engines. That means more visitors, better user privacy, and cheaper maintenance. It’s more accessible to both end users AND internal users making changes.
Building an accessible website requires intention, context, and attention to detail. When accessibility is prioritized from the beginning – at the level of information design and the website’s overall architecture – it’s more sustainable and easier to make changes in the future. That’s why we like writing websites in plain HTML when the situation calls for it, and love tools like Jekyll and Eleventy that make this approach scalable for sites of any size.
Thinking about making your own site more accessible? The WAVE tool and browser extension is free, and it’s an easy way to judge how a screen reader tool would interpret a website. Try it on yours and reach out to us if you have questions!