Accessible Website Build & Rebrand Series Overview:
Building a new website is an inevitable project for many marketing directors. There are many driving factors, from inheriting an old website that underperforms to a company rebrand. Perhaps the old website lacks the ability to scale and integrate technology as the business grows or just doesn’t possess operational efficiencies and it takes forever to do anything on it. Regardless of the reason, it’s a common occurrence for a director to oversee a new website build.
In my 10 years as director of digital marketing in the digital agency world, I supported dozens of new website launches. However, it wasn’t until I went in-house in as the head of marketing for a B2B SaaS organization that I became fully responsible for an end-to-end build that required architecture, design, building, messaging, and a successful launch.
Since then, I’ve built multiple websites using a combination of technologies, platforms, and partners. I’ve learned a lot over the years and view this knowledge as a competitive differentiator in helping the organizations I’ve worked for to succeed.
TPGi Website and Rebrand Project:
However, my most recent project was different—in a big way—and has changed my mind about disclosing what I’ve learned. I was tasked with building a fully accessible website as part of an organizational rebrand that would transform The Paciello Group into TPGi. Along with a non-negotiable accessibility aspect, the site also needed to meet the demands of a modern high-performance marketing organization.
Note that “accessible,” when held to TPGi’s standards (which truly align to the WCAG standards and pass the scrutiny of some of the world’s leading accessibility engineers) is a completely different bar from what most organizations aim for. This is important for later topics.
Why This Content Series?
Not everyone has this same resourcing I have access to at TPGi, so this content series is dedicated to documenting the project from concept to delivery, and includes all the key things that happened in between. I am sharing my playbook, project plan, templates, processes, tools, lessons learned, and valuable insights to reveal the process, plan, and methodologies you need to build your own accessible website. Of course, if you need further help along the way, TPGi can be a valuable resource to you. (Contact us for help!)
Most of the assets I discuss in this content series (including my project plan worksheets, accessible style guide, and ARC accessibility analytics) will be available for free. I am publishing the first topic in the series along with the introduction and will be launching a new topic monthly. Check out the list of topics below and dive into the first topic (which gives you a free Excel project plan to help you get organized).
Topics of the Content Series:
- Topic 1 – Project Plan for Building an Accessible Website
- Topic 2 – Technology Evaluation and Selection
- Topic 3 – Development Partner Evaluation and Selection
- Topic 4 – Website Architecture and Sitemap Planning
- Topic 5 – Visual Identity Creation and UX Integration (Logo and Style Guide)
- Topic 6 – Design Comps, Wireframes, and Creative Builds
- Topic 7 – Development, Templates, Components, and Accessibility Integration
- Topic 8 – Content Production and Migration
- Topic 9 – Martech Integrations (Hubspot, Google Analytics, Crazyegg, etc.)
- Topic 10- Quality Assurance Testing and preparing for production release
The Project Goals:
My objective was to deliver a completely new brand, logo, and design, refreshed messaging, new conversion paths, user flows, analytics, new platform, new architecture, consolidate multiple blogs, and provide a means for our marketing organization to rapidly produce new ideas, product pages, and campaign landing pages. We also needed the ability to integrate key marketing technologies like Hubspot as well as easily update and maintain pages. A critical requirement for the website was “minimal time to get from concept to delivery” for ideas. It had to perform well, load fast, deliver marketing results, and of course, be accessible.
The Challenge Ahead:
A project of this scale is big to begin with. Yet, I had gone through this process several times in the past and knew what tools, technologies, and processes to use. I had a playbook that had historically worked well and was ready to tackle this challenge.
“Wait, scratch that. I ‘thought’ I was ready to tackle this challenge. I quickly found that most of the publishing platforms I’d used in the past didn’t deliver when it came to building fully accessible websites.”
It was a rude awakening to learn that the tools and platforms I’d previously leveraged weren’t going to cut it. They weren’t accessible and our engineers didn’t have the ability to modify or fix the underlying issues. Time to update the playbook!
The current website I was replacing was built by accessibility engineers to communicate basic information—the equivalent of a digital business card. Regrettably, it was not built with modern high-capacity marketing operations in mind. It was basically HTML code on a per-page basis without any front-end creation and management tools.
Now I understood why this system had persisted for nearly six years before I arrived. No off-the-shelf content management systems, page builders, or components (that I found) exist that conform to TPGi’s (and WCAG) standard of accessibility, which meant I had to approach this problem differently than I had in the past.
Building my own accessibility components
If you are familiar with different types of CMS/publishing platforms, you’ll know there are a couple of different types. The more traditional CMS where you design templates and use those templates to build out your website requires additional coding when you need to modify your template—which means less page-to-page customization flexibility. Hybrid composition engines like WPTF, Elementor, Divi, Wix, Hubspot COS act more like a page builder and framework for building on. Such solutions offer a ton of flexibility within a page and allow you to produce a wide range of website or campaign pages on the fly without needing to code.
With the website I inherited, structural changes had to be custom-built by an accessibility engineer. If I had a layout change and wanted to add a new content section, I had to spec the project, meet with engineers, get an estimate, and then scheduling the work. This often took weeks, whereas with some of the newer page builders I had used in the past, I could make similar changes in a couple of hours.
Not having the ability to personally modify anything more than minor content on our site was a challenge that significantly slowed down marketing operations and required internal resources that were needed for client work. We needed a new solution that empowered the marketing team while still achieving our accessibility goals.
Enter the Solution:
They say necessity is the mother of all inventions—well except for this entire subreddit dedicated to unnecessary inventions. Joking aside, we had a very real business need, but couldn’t find an off-the-shelf solution that upheld our accessibility requirements and provided the flexibility our marketing organization needed to streamline the build, management, and optimization of a new marketing website.
“There was a gap in the market. I needed to provide the marketing team with the capabilities to produce and optimize content while ensuring we met the accessibility requirements that TPGi demanded. Out of necessity, I set my sights on building a custom accessible page builder.”
I was fortunate enough to work with three UX engineers, five or six world-class accessibility engineers, and a team web of developers supporting various aspects of this project. Learn more about the technical solution in this post (coming soon!).
I had to restructure my playbooks, project plans, and methodologies to incorporate accessibility at virtually every layer, including design, branding, coding, and QA. Yet, we ultimately ended up delivering a modern, world-class accessible marketing website with all the key capabilities you would expect with a cutting-edge page-builder platform.
I intend for this series to enable readers to learn from my experiences, gather documents or other elements to help in their delivery, and ultimately deliver an accessible website (whether it is part of a rebrand or not). If you have any questions, please feel free to reach out via email at firstname.lastname@example.org.