
If your agency is new to including accessibility in your website builds, you may be unsure how to price accessibility into new website design and dev projects. How do you set accessibility pricing that fits seamlessly and profitably into your website projects?
This article explores how accessibility pricing integrates seamlessly into various website project types. By breaking down accessibility delivery into manageable steps, it becomes easier to craft pricing strategies that align with client needs and project goals.
Read on for practical insights, including simple formulas for calculating accurate estimates.
Determining Scope and Budget by Project Type
For the purposes of determining accessibility pricing, we are going to lump all website projects into two key categories: Template, Pre-Buit, or Off-the-Shelf and Custom Built Websites. What follows is a brief explanation of each type of project and the high-level accessibility considerations unique to each.
Template, Pre-Built, or Off-the-Shelf
These engagements involve using templates or themes that are readily available and can be quickly customized to meet specific needs. These solutions are often more cost-effective and time-efficient, making them an attractive option for clients with limited budgets or tight deadlines.
When it comes to accessibility, it is critical to spend time understanding how and to what level each theme, block library, or page builder you plan to use observes accessibility best practices.
If accessibility barriers are identified, you can ask product owners to fix accessibility deficiencies in their products, potentially saving your team time. But, depending on the product, your requests to fix issues may get delayed or archived without a resolution. This could put your team in a challenging position if the page builder you chose has poor accessibility implementation and refuses to release a patch.
Choosing the right theme and plugins is vital for reducing the time you need to budget for in testing and fixing these website projects.
Custom Built Websites
Conversely, custom website projects are built from scratch and tailored to the client’s specific requirements. This approach provides greater flexibility and allows for unique design elements and functionalities perfectly aligned with the client’s vision. Custom websites are ideal for businesses that require specialized features or layouts that can not be found in mass-market options. Of course, the trade-off is that this approach typically requires more time and investment.
When it comes to accessibility, building custom solutions can be a double-edged sword. On the one hand, you have all of the capabilities and none of the limitations to build a fantastic, accessible solution for your client. On the other hand, most of the implementation of accessibility best practices will be up to your team (and any contractors you bring in) to both identify and correct accessibility deficiencies.
To reliably deliver accessible outcomes in this type of project, heavily dialed-in processes around testing early and often for accessibility will be essential. If your team doesn’t think about accessibility early in the process (such as choosing accessible color combinations in design or using semantic components in when custom blocks), you may have to go back and rebuild elements, which significantly cuts into profits.
Article continued below.
Stay on top of web accessibility news and best practices.
Join our email list to get notified of changes to website accessibility laws, WordPress accessibility resources, and accessibility webinar invitations in your inbox.
Accessibility Pricing Breakdown
For profitability and time-efficiency, it’s important to not save accessibility testing until the end. Shift accessibility left in the design and development process. This may add time to the earlier stages of a project but it will save the team more time later by preventing errors from happening in the first place. When pricing accessibility include it in the budget for design, plugins/tools, quality assurance testing, and development. Accessibility should be priced into every phase of the project.
Pricing Accessibility Review in Design
Budgeting for an accessibility review during the design phase is a smart investment that can save time, money, and frustration down the line. Addressing accessibility early ensures that potential barriers are identified and resolved before coding begins, where changes are more costly and time-consuming. By integrating accessibility into the design process, you reduce the risk of delays, enhance client satisfaction, and position your agency as a leader in delivering thoughtful, inclusive digital solutions.
When writing website proposals, include at least 1 hour per designed page for an accessibility review. So if your hourly rate is $100 and the project scope includes 6 designed pages, the design accessibility pricing would be at least $600. This should be included in the design fees, not line-itemed separately, as it’s just quality control on your designs.
Budgeting for Automated Testing Tools
Including automated testing tools like Accessibility Checker in the budget for a new website development project is essential for streamlining quality assurance and ensuring accessibility compliance. These tools help identify code issues and accessibility barriers early, reducing the time spent on manual reviews and costly revisions.
By integrating automated testing from the start, you can catch problems before they become significant setbacks, allowing your team to work more efficiently and deliver a polished product faster. This proactive approach enhances client satisfaction and increases overall profitability by minimizing rework, improving project timelines, and positioning your agency as a tech-savvy, reliable partner.
We recommend including an Accessibility Checker Pro or Accessibility Checker Small Business license in every new website proposal. The pricing for this is $149-$600 depending upon the needed features.
You’ll also want to consider the time it might take for someone from your team to review Accessibility Checker reports and open issues for your dev team during the quality assurance (QA) phase of the project. This may add several hours to your QA budget, depending on the developer’s diligence while building pages and components. The more problems that exist, the longer it will take to report all the problems.
Pricing Accessibility Auditing per Page
For template, pre-built, or off-the-shelf websites, pricing accessibility per page is often the most straightforward approach. You don’t need to manually test every page. Use automated testing tools to scan the entire website and then budget for manual review of key pages.
Determine Which Pages Need Manual Audits
To price accessibility auditing, you need to identify pages with key elements and ensure you’re testing at least one instance of each. Items to look for include:
- accordions
- tabs
- forms
- modals, lightboxes, or popups
- carousels or sliders
- maps
- search and filters
- post grids or lists
For more information on identifying elements or pages that need to be audited, watch this Accessibility Strategy and Goal-Setting Workshop webinar. Once you have identified the key pages that need testing, you can arrive at pricing for auditing those pages.
How Much Time to Audit Per Page
In our experience, it takes an accessibility tester between 3-4 hours to test and report issues on a header and footer and 1-3 hours for the content area of a web page of moderate complexity.
The largest amount of time in manual audits is not the time to find the problems but is the time spent logging them and providing recommendations for fixes. Pages with more issues take longer to audit, which is why it’s important to fix issues that can be identified with an automated tool first. Doing this will reduce the cost of a manual audit.
When setting manual accessibility audit pricing, the first page is the biggest time investment because it includes the header and footer. From there, you can calculate pricing based on a smaller per-page fee.
Here’s an example formula for this:
First page hours + ( content area hours x (# Pages You Will Build)) = Approximate Testing Time
This formula is the number of hours to test the first page (header, footer, content area) added to the number of hours for additional content areas times the number of pages to be tested.
In our example of a 6-page website, assuming it takes 5 hours to test the home page and 2 hours to test additional pages, this would total 15 hours of testing time. If your hourly rate is $100, the pricing from manual accessibility testing in this scenario would be $1500.
Pricing Per Unique Component
For custom-built websites, pricing accessibility by unique components allows for a detailed breakdown of costs based on specific features and functionalities. For instance, a custom-built learning management site may have multi-step checkout processes, a multitude of different course views and galleries, and user accounts. Pricing these components separately ensures each element is accessible and reduces the likelihood of budgeting or scoping oversights.
In our experience, components break down into:
- highly complex full-page components
- moderately complex partial-page components or sections, and
- low-complexity components that are “variations” of the former two (e.g., a slight change to a component based on user input or settings but does not represent an entirely new component).
It could take an experienced accessibility tester up to 8 hours to test a full-page component, 2-4 hours to test a partial-page component, and 1 hour or less to test a “variation” of a component with only minor changes from the original.
To calculate pricing on a per-component level, the team responsible for scoping would first need to anticipate the total number of full-page, partial-page, and “variation” components that will be included in project scope (this is no small task, it can take hours!). Plan to test every block and shortcode and variations on them based on settings in the editor or via shortcode attributes.
From there, multiply each type of component by the corresponding average time to yield a total for testing time and component-based testing fee.
Pricing Accessibility in Dev Budgets
You’ve found the accessibility problems, but someone still has to fix them. That takes time, and we have a rule of thumb for you.
When providing estimates for the first project that has accessibility as a component, we strongly recommend adding a 20-30% buffer to your dev budget.
Depending on your team’s dev skills, remediating identified issues can be easy or it can be extremely difficult. The first time any individual or team engages in a new type of project, there are very likely to be inefficiencies and learning experiences, and building sccessible websites is no different. We have seen teams who, unfortunately, needed to rebuild every component after an audit which meant a doubling of time in scope.
Make sure to increase your development or revisions budget to account for extra time needed to fix issues, but also make sure you “shift left” and start testing for issues early so you don’t get too far into development with problematic components.
If you know your dev team builds websites with existing tools rather than coding them from scratch, you may want to up the dev budget even more than 30%.
Need help with accessibility pricing?
Ensuring your team can deliver an accessible site profitably doesn’t have to be overwhelming. Let our expertise guide you in making the right choices for your needs. Reach out today for a personalized consultation and take the first step towards bigger, more lucrative projects.