This is Topic 2 in the Website Rebuild Series – View the Series Overview Here.
I started the technology selection process with a couple of non-negotiable business and technology requirements. At the top of the list was ensuring our marketing team had the ability to create a wide array of page types (product, landing, form, info, educational, etc.) and easily customize layouts.
I wanted the efficiencies of a modern page builder (like Elementor or Wix), but the code output had to be clean, fast, mobile-responsive, cross-browser compatible, and fully accessible. Accessibility aside, I found it challenging at times (putting it lightly) to get Elementor to work well across browsers and devices. In order to achieve this, we would need the ability to edit/modify all the various code layers. The last thing we wanted was to end up in a situation in which we found a significant accessibility issue that we were unable to resolve because we couldn’t access the code.
Website Business Requirements
- Must provide non-developers/engineers the ability to create, build, modify, edit, and publish a variety of layouts
- Must have an easy-to-use form management system with page-level editable configurations that integrate with Hubspot API
- Must provide common/global components that can be edited and will update the entire site where that component is used
Website Technology Requirements
- Have full access to underlying code structures
- Deliver an accessible user experience
- Needs to be responsive, cross-browser friendly, and fast loading
Existing Tech Evaluations:
I evaluated multiple page builders in the early stages of this project to see if they met the accessibility requirements of this project but quickly found that the dominant publishing platforms failed to meet all of my core requirements outlined above. One of the main issues we encountered was a balance between the ability to create different content types and access to the code itself. If it allowed for a ton of producer flexibility, we couldn’t access or modify the underlying code. If we could directly control and build the code ourselves, it tended to restrict our flexibility. Moreover, there were several accessibility “deal-breakers” with a lot of the technologies we explored.
Defining our Tech Stack:
After assessing our options, we determined we would have to build our own components from scratch. The components would need to provide us flexibility as content creators, but would also prevent us from writing “bad” or inaccessible code. We opted to use WordPress as the base platform due to the massive user adoption, open-source framework, and wealth of resources available.
I used Advanced Custom Fields in the past but only those within defined templates: You could modify an image or text easily, but to change the structure of the page or reorder elements, you would need to change your template. This extra step meant more developer support and coding, which did not meet our primary business requirement. I wanted to separate the content from the page so that the underlying code structures could be managed and updated without having to resort to page-level styles or inline code.
We ultimately created multiple ACF components that had an appropriate amount of producer flexibility but also ensured each component’s output was accessible. We started with a “blank” page-level template that really only consisted of a header and footer, global elements that would not change much on a page-to-page basis. We also provided several options that could be toggled on/off on a page level, such as:
- A “hero component” that could easily communicate what the user could expect to see on the rest of the page
- An ”in-page navigation bar” above the hero but beneath the main navigation
- A footer CTA form
Note that while we opted to create the “in-page” navigation so it appeared to be part of the primary navigation, it was really a page-level component that could be modified at will.
Watch a Quick Overview Video to see how the components work together:
Flexible Component Overview:
We built a handful of custom components that could be dropped into the body of the page and reordered as desired. The most useful component is our “Flex Component Module.” This module gave us immense structural control over the page; for example, if we wanted a single column width in one section and two columns in another, we could easily achieve this by stacking the modules. The combination of our new Flex Component along with the other components allowed us to create “templates” for primary pages, which we could then use to quickly and easily produce multiple variations containing different content.
Once we were satisfied with our Product Overview page, for example, we cloned it and swapped our content, images, text, etc, to build the next page we needed to create. Though we used these “template” pages as the foundation to build out all the content on the site, we weren’t tied to any of them—we could easily modify each individual page as needed.
We built our website using a combination of WordPress, Advanced Custom Fields (ACF), and WPengine. Our development partner on this project was Windmill Strategies (specifically Jen Brigham, who served as the lead developer on the project). We had multiple TPGi accessibility engineers and UX designers involved from the onset of this project to achieve a technical infrastructure that allowed us to satisfy both business and technical objectives.
The framework we developed can be used to rapidly produce new accessible websites, primarily of the B2B and lead-gen types. It offers non-developers an easy way to build and maintain a wide variety of accessible website layouts and designs, without having to start from scratch or break the bank.
If you are interested in learning more about our TPGi Accessible WordPress Page Builder, shoot me an email at bhenry at TPGi dot com. If there is enough interest, I will make this platform available as a beta for others to experiment with and hopefully get as much use out of it as I have.