Ultimate Guide to Building an Accessible Website (Topic 1: Excel Project Plan)
Building an accessible website starts when you are beginning your strategy and planning phase. There are several considerations to incorporate into your project plan, budgeting, resourcing, and timelines. Adding requirements to ensure a quality standard like accessibility does add layers of complexity, and failing to recognize and plan for this upfront will create frustrations and failures down the road. This post focuses on the planning, strategy side, and project plan framework to ensure organizations are set up for success. The overall series will dive deeper into production stages throughout the accessible website build project.
The first thing you need to do as part of building an accessible website is set up a project plan framework that embeds accessibility into the core project elements. Such a framework needs to be easily customizable, shareable, flexible, and provide stakeholders with key visibility while also providing resources and information they need to prioritize. The framework also needs to be able to deliver elements that build on top of each other in the right sequences.
Download FREE Excel Project Plan
Key Project Plan Elements:
Overall Timeline:
Projects similar to TPGi’s new website relaunch can easily take 4-6 months on average, even if you don’t rebrand. Your project timeline will depend on multiple factors, including if you plan on rebranding, are building components from scratch, or are able to use existing frameworks/components. We knew that we were going to have to build from scratch to maintain full control over the code, as we could not risk producing a website with certain inaccessible elements. In all, it took about six months of effort.
While “Agile” methodology is all the rage today, our particular project had several cascading initiatives and we had a very specific sequence of events and timelines we had to hit. I found a waterfall approach mixed with some of the beneficial aspects of agile including sprint efforts worked best. It probably maps most closely to The Agifall Model
I used the right-hand side of the plan to create a Gantt Chart for visualizing how the stages align, overlap, and communicate progress with key stakeholders. You can modify these as needed in your plan.
Budget:
Ensuring accessibility does require extra time when it comes to strategy, planning, resourcing, development, and especially the QA and remediation. Your budget will depend on the level of accessibility requirements, your build strategy, and whether you are building new components from scratch or using existing CMS. You can expect to allocate an additional 25-50% on top of a typical website build process, both in terms of cost and time to achieve a high degree of accessibility conformance depending on your conformance goals and technology selections.
Resourcing: “Roles” Tab
There is a specific tab in the project plan used to identify all the various roles and how they contribute. Determining the overall project lead, leads across various activities, contributors, and stakeholders is a critical initial step. Filling these roles is helpful for scheduling a project kickoff, checkpoints, and communication needs.
We had a combined 20 “roles,” including those from messaging, design, UX, accessibility engineering, SEO, analytics, HR, IT, Mar-tech, and various business unit stakeholders. Some people covered multiple roles, but this gives a sense of the scale of an initiative like this (regardless of accessibility) and why it can be a good idea for everyone involved to understand the relationships in a project. Our initiative involved a full rebrand, which added layers of complexity for design and approvals. You may want to reduce the scale accordingly if you are only rebuilding a website and not creating a new brand identity.
One of the biggest threats to your timeline will be getting all your stakeholders and contributors to deliver on their responsibilities in a timely fashion. They all have other responsibilities outside of this project which can easily take precedence over their responsibilities for your website build, creating lags in delivery that can build up when there are other dependencies in the workflows. This isn’t to fault them individually, but it is a practical reality of your project that you have to recognize upfront and manage accordingly as the project moves forward.
Communications:
There are different communication needs for various roles. Establish a core team of decision-makers (usually a team of 2-4 individuals): a project lead, a primary contributor, and primary stakeholder. Create a weekly meeting cadence and use a recurring meeting for this to keep the initiative front and center.
Establish regular communications on a monthly cadence for the rest of the contributors and stakeholders where you provide updates and listen to questions, ideas, and other issues that might be surfacing. I found flexibility in scheduling stakeholder updates to align to achieving key checkpoints worked better as the updates were more meaningful.
There will, of course, be kickoff meetings, ad-hoc meetings, and several other sub-group meetings as well. Set expectations up front, but provide individuals a path to communicate with you directly as needed. I set up a Microsoft Teams channel to facilitate better cross-functional communications
Sharing and involving stakeholders early on will help to increase buy-in and approvals. Don’t worry too much if critical items like branding or website designs take a couple of rounds of feedback and approvals. Taking a collaborative approach will help improve the overall results and reduce the risk of larger issues post-launch.
Website Rebrand Tab Sequential Stages and Deliverables:
The project plan is partitioned into deliberate phases of the build. You can easily expand or collapse all of the phases by clicking on the 1 or 2 in the plan.
At the start, knowing what you are going to build is equally important as the how and when. Defining your MVP, phases, mar-tech stack integrations, and what technologies you are going to build are all critical planning decisions. Define your content and information architecture to support those goals, in addition to the actual content, product, and lead-gen goals. There is an MVP tab where you can document launch expectations.
I tend to break down the website build processes into a couple of critical categories, with a fair bit of overlap as it can be difficult to completely partition content/design (and I don’t advise completely separating these).
- Strategic Planning and Communications
- Content and Information Architecture
- Branding Definitions
- Design Comps and Creative
- Technical builds: Structural Elements, components, and templates
- Content Production and Migration
- Mar-Tech Integrations
- Staging, QA, and release preparation
- Launch scheduling
Components KanBan Tab:
In the “Components” tab, it is important to evaluate the HTML outputs of the underlying components or templates that your site will be built on. Establish a means to evaluate these for accessibility approvals before you begin to use them to build your website. If there are issues at this level, it will create hundreds or thousands of accessibility violations, as a single component can be used across several pages on your website, especially if it’s part of a template.
Page-Level KanBan Tab:
In the plan, there is a primary project plan timeline which is critical, but I also created a Kanban page-level tracking tab. A Kanban is incredibly helpful once you have the templates or components to actually build and/or migrate content and images. Every page will need content, graphics, SEO, QA (including accessibility testing), and ultimately approval for go-live. You may want to update this tab to include any additional layers of tasks your org needs on a page level.
Accessibility Issues Doc:
Whether you are using a modern tool like ARC Monitoring to surface accessibility issues or some combination of automation and manual engineering review, you’ll need to document all the cases and establish remediation, retest, and verification process for accessibility issues. At TPGi, we used a combination of ARC Toolkit, ARC Monitoring, and manual accessibility testing and tracked all concerns through a shared word doc, labeling each issue. If you don’t complete everything before launch, you can use this document to seed your post-launch accessibility backlog. Work with engineers to prioritize the issues that prevent people with disabilities from completing the key tasks on your website. Setting up ARC User Flows is a great way to surface and prioritize those critical flows.
Related Tasks Tab:
If you’re rebranding in addition to building and launching a new website, there are several tertiary activities. Go ahead and establish a running list of the “knowns” you must update to accommodate new branding. This can be anything from physical signage, business cards, internal portals, accounting documents, bank accounts, apparel, and almost anything between. I left a good sample of some of our related rebranding tasks.
Final Stretch Tab:
As you get closer to your launch date, things may start to feel hectic. I find it valuable to create a day-by-day checkpoint as you enter the final two to three weeks before the production (live) release. This is where I map all the final to-do’s, who’s responsible, and deadlines for deliverables. Managing this daily helps you keep the train on the tracks as it comes barreling down the mountain!
In this tab, I segmented launch and near-term, post-launch activities. These activities can include everything from changing your DNS to press release distributions to update Google Analytics goal URLs. You will also have launch campaigns that are usually tracked and managed separately from the actual build project plan.
Summary Remarks:
This project plan is a guide and suggest making it your own and adjusting for your business needs. It should provide a solid structure and the flexibility needed to achieve this. I have used some variant of this plan to successfully launch multiple organizations’ rebrand websites, and hope you can get as much value out of this as I have.
