Accessible WordPress Page builder

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 WordPress page builder (like Elementor, Divi Builder 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

Evaluation of Premium Page Builders:

I evaluated multiple popular page builder platforms 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 which would provide us with complete control of our site. If one visual builder allowed for a ton of producer flexibility to create custom layouts and templates, we couldn’t access or modify the underlying code. If another layout builder allowed us the ability to directly control and build the code ourselves, it tended to restrict our flexibility and design options. Moreover, there were several accessibility “deal-breakers” with a lot of the technologies we explored.

Defining our WP Page Builder Tech Stack:

After assessing the popular WP page builder options, we determined we would have to build our own components from scratch. The components would need to provide us with the ability to produce flexible custom page layouts 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 pre-built templates: You could modify an image or text easily, but in order to create custom page layouts and change the structure of the page or reorder elements, you would need to change your WP page 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 content elements that would not change much on a page-to-page basis. We also provided several powerful features 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 accessible visual page builder and components work together:

 

Powerful Design Options:

We built a handful of custom components that could be dropped into the body of the page and reordered as desired. The most useful design block 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 “prebuilt 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 “prebuilt accessible 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 with custom designs as needed.

Summary:

We built our website using a combination of WordPress, our WP Page Builder, Advanced Custom Fields (ACF), and WPengine. Our development partner on this project was Windmill Strategy (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 WP Page Builder, send us an email at ida at TPGi dot com. If there is enough interest, we may make this platform available as a beta for others to experiment with and hopefully get as much use out of it as we have.

 

Categories: Business

About Brad Henry

Brad Henry is the Director of Marketing for TPGi. With 15+ years of experience in digital marketing with a focus B2B SaaS, e-commerce, and data/analytics, he brings the perspective of content creation and digital property ownership to the accessibility space.