Product-led Growth
Buy vs Build: Accessibility Checking feature cost estimate
Published February 2nd, 2022
![](\"accessibility.png\")
Creating and publishing websites, apps and content that are both well-written, and accessible, is notoriously hard. It’s so hard that many avoid doing it. However, it’s not just the designing, it’s also the functionality, compliance, and maintenance required to ensure websites keep up with constant changes to the global accessibility guidelines.
Di Mace
Communications Specialist at Tiny
Why else is it hard? Because most people don’t have the inhouse experience or knowledge, and it can be expensive and time consuming to hire an accessibility expert to review all your designs and content.
What's the answer? An accessibility checker. They help developers, creators, and designers to create high quality websites, mobile applications and content that don’t exclude anyone – as well as supporting the evolution of both accessible design and functionality.
But what’s involved in building a best-in-class, feature rich accessibility checker? And how much would that cost… versus buying a third-party component and assembling it as part of your tech stack? Let’s find out.
New to the idea of accessibility checking? Read more...
Complexities of building an accessibility checker feature
Web accessibility is a specialized field that impacts devices from mobile to desktop computers, as well as the assistive technologies (like braille or screen readers) that work on those platforms.
For developers new to this space, the rules and guidelines can be easily misinterpreted. This can lead to the wrong solution implemented – which may not be helpful to users who require assistive technologies to consume and interact with content.
What does an accessibility checker do?
An accessibility checker ensures that content created by the rich text editor complies with the globally recognized accessibility standards. This allows all readers or consumers of content to share the exact same content experience that the author intended and without discrimination or limitations.
What functionality is crucial to an advanced accessibility checker?
An advanced, feature rich accessibility checker needs to simplify the process of ensuring that the content created adheres to modern accessibility standards and best practices.
It needs to:
- Create an intuitive auditing workflow that analyzes the underlying code for any issues that could cause screen readers and assistive technologies to fail.
- When problems are found, the tool should provide options on how to correct the issue (as part of the auditing workflow), to ensure that only clean compliant code is published.
- The accessibility checker must adhere to the recognised WCAG 2.1 specification, taking into account that the specification allows for different levels of compliance (ranging from A to AAA), with AAA being the most stringent set of accessibility rules.
- An advanced accessibility checker should allow the content author to set the level of compliance that they want (ie A to AAA). This feature helps authors who have large content stores to gradually improve compliance over time, as certain changes could require structural code changes which may not always be feasible.
- Ideally, the tool should be used programmatically via its APIs, thus allowing developers to further automate accessibility checking as part of their quality control process.
PREFER USING APIs?
Check out our APIs for these premium plugin/features:
What expertise is required to build an effective and compliant accessibility checker?
- An understanding of how to traverse and manipulate the HTML DOM in order to find and fix issues
- The ability to pick out the most common problems and/or the most problematic mistakes that users can make
- Both a broad and deep understanding of WAI-ARIA and WCAG rules and how they should be implemented:
– Many of the accessibility rules can be confusing (e.g. slight variations for very specific cases, seemingly contradicting rules with nuanced differences etc), so the checking tool needs to balance checking everything important and not overwhelming the user.
– The level of checking (see above section on WCAG level of compliance from A to AAA) should be able to be customized and allow for some websites, apps and platforms that have custom HTML (e.g. widgets, third party widgets etc) to not be checked, if the author doesn’t want it done.
- A thorough knowledge and understanding of how different browsers and accessibility tools handle accessibility related HTML features:
– With screen readers, there are many instances where they read HTML differently, or require different HTML to read anything at all, so you need to know how to write accessible HTML so that it works for all screen readers, or as many supported screen readers as possible.
– It’s unknown which screen reader the person is using (and unlike OS, browsers etc that can’t be detected), so the HTML needs to be written in an accessible format.
- Experience working within the accessibility field, and proficient in the use of different assistive technologies tools utilized for testing.
- Knowledge of UX workflow design and how to make it simple for writers to use and correct issues.
As you can see, building your own accessibility checker requires a comprehensive knowledge of accessibility – not only for its initial development, but also its ongoing maintenance and extensibility – to maintain compliance with rule changes, across the world.
![](\"frame-30-copy-2021110813411567.svg\")
Cost Estimate for an Advanced RTE Accessibility Checking Feature
Building an advanced feature like an accessibility checker, doesn’t start and end with the development and building phase. It also requires ongoing maintenance and extensibility work through the life of the feature.
In practical use, the checker sits on top of your rich text editor content, and therefore also on top of all the plugins that affect that content. Therefore, the accessibility checker needs to effectively interact with all your advanced (and basic) features and plugins, as well as any combinations of them on an ongoing basis.
Any features progressively added to your editor that affect either the content’s HTML or that browser’s release, could therefore spark further changes that need to be implemented within your accessibility checker. By way of example, here’s some potentially bad interactions with other plugins:
- In some cases, interactions with an advanced copy and paste feature could certainly be a concern (mostly for MS Word, MS Excel and GDocs content).
- Image plugins also need to be compatible, to ensure they have the same definition of decorative images.
- Changes made to the structure of tables plugins can also cause potential problems due to the labeling of the columns and the way that screen readers ‘see’ tables.
All of these complexities and interactions need to be factored into the total cost of ownership (TOC) of the plugin.
![](\"bookmark.svg\")
COST ESTIMATE CURRENCY
All cost estimates quoted are in US$
This includes development/build work, maintenance and extensibility work
Curious about the cost of building your
own rich text editor?
Read the total cost breakdown in: Buy vs Build White Paper
Cliffnotes: Tiny puts price tag on building your own rich text editor
Plus, get the cost breakdown of building, maintaining
and extending advanced features:
Build/Development – 1 x RTE Accessibility Checking Feature Cost Estimate (excl. core editor)
Using a normalized COCOMO Model, the estimated engineering requirements for building a single advanced accessibility checking feature, are:
- A Senior Software Engineer
- Average salary rate (US$128,749** p/yr excluding oncosts, RSUs and bonuses)
- 24294 lines of code (The LOC includes the plugin itself, as well as the dependent core libraries that are maintained ongoing, as part of the feature)
- 98.2 person-months of effort = 15.8 months using 8 developers
- Excluding ongoing maintenance and extensibility work
- $35K to purchase a specialist accessibility audit of existing content.
Accessibility audits provide a detailed analysis on how to maintain industry compliance and ways to improve content accessibility for readers. This external report helps form the product roadmap for any rich text editor (RTE) development work. Without an advanced accessibility checker plugin in place, this report needs to be updated annually
EQUALS = $1,053,278 in development cost
PLUS\t\t+ $35,000 for specialist accessibility audit
TOTAL\t\t= $1,088,278
Advanced RTE Feature COCOMO Modeling
Software Development (Elaboration and Construction)
Effort
98.2 person-months
Schedule
15.8 months
Cost
$1,053,278
total equivalent size
24294 SLOC
effort adjustment factor (EAF)
1.00
Acquisition Phase Distribution
| Phase | Effort | Schedule | Average Staff | Cost |
|---|---|---|---|---|
| Inception | 5.9 | 2.0 | 3.0 | $63197 |
| Elaboration | 23.6 | 5.9 | 4.0 | $252787 |
| Construction | 74.6 | 9.9 | 7.6 | $800491 |
| Transition | 11.8 | 2.0 | 6.0 | $126393 |
![](\"Accessibility.svg\")
It should be noted that the above $1.1M estimate for a single advanced accessibility checking feature, excludes the additional support costs required for the development of a product ready feature:
A full time Senior Product Manager***
- During the Inception/Discovery Phase
- Throughout the 15.8 months of the project
A full time Senior Product Designer****
- 1 week during the project
Ongoing Maintenance – 1 x RTE Accessibility Checking Feature Cost Estimate (excl. core editor)
Extensive engineering time and resources is required to both maintain and evolve the feature to keep pace with market, feature and related plugin changes.
- Expect to dedicate a minimum 105 full time work days (3.5months) per year, every year of the plugin’s life, of Senior Software Engineer** resources, to keep the accessibility checking feature afloat
- Average salary rate (US$128,749** p/yr excluding oncosts, RSUs and bonuses) or $10,729.08 per person-month
- This work would include bug fixes, other tasks and various required maintenance.
EQUALS = $37,552** yearly in maintenance cost for a single feature, ongoing
PLUS
- A full time Senior Product Manager*** throughout any maintenance work.
- A full time Senior Product Designer**** sporadically during maintenance work.
An accessibility checker plays an integral role in both government and legal compliance. Governments and industry bodies can introduce legislation and/or policies that affect web content accessibility (sometimes with very short implementation lead times), that in turn may require an immediate change or update be made to the plugin.
Although WCAG doesn't often bring out new specifications (e.g. 2.0 in 2008, 2.1 in 2018, 2.2 currently being worked on), when they do, there might be a lot of maintenance work needed to update the checker to align with the new specifications. There's also the consideration of whether to maintain both the old version and the new version, or just do an update – that decision has longer term impacts on maintenance costs (maintaining both = more maintenance).
The additional ongoing maintenance, infrastructure and QA requirements for all rich text editor advanced features, include:
- Continual testing and keeping development infrastructure up to date. This is the biggest consumer of engineering time and cost, to ensure the engineering team avoids the accumulation of technical debt (due to dependencies not being kept up to date and having to constantly play catchup).
- Having sufficient licensing across all supported platforms (eg all the versions of MSWord, for testing)
- Balancing the prioritization of plugin maintenance over primary features (productivity vs core product revenue).
Long-term Extensibility – 1 x RTE Accessibility Checking Feature Cost Estimate (excl. core editor)
Extensibility work isn’t always easy to predict or plan, especially when the accessibility guidelines are governed by a body external to your engineering team and timetables.
- Every other year at a minimum, expect to dedicate at least 51 full time work days (1.7months) of Senior Software Engineer** resources, to account for larger changes in accessibility guidelines.
- Average salary rate (US$128,749** p/yr excluding oncosts, RSUs and bonuses) or $10,729.08 per person-month
- This extensibility work includes feature requests and extensions and well as maintaining pace with market developments and changes in user needs.
EQUALS = $18,239** in extensibility cost for this single feature, biannually ongoing
PLUS
- A full time Senior Product Manager*** throughout any extensibility work.
- A full time Senior Product Designer**** sporadically during extensibility work.
TOTAL COST ESTIMATE for an RTE Accessibility Checking Feature (excl. core editor)
- $1,053,278 build/development cost
- $35,000 specialist accessibility audit
- $37,552 p/yr in maintenance cost, ongoing
- $18,239 biannually in extensibility cost, ongoing
$1,144,069 TOTAL COST
Note: All estimates exclude on-costs, RSUs and bonuses
* Using the Basic COCOMO Model (Accessed 1 July 2022)
**Average base salary for a Senior Software Engineer is US$128,749 per year in Silicon Valley, CA
*** Estimated base salary for a Senior Product Manager is US$157,340 per year in Silicon Valley, CA
****Estimated base salary for a Senior Product Designer is US$145,700 per year in Silicon Valley, CA
(All salary rates accessed 1 July 2022)
A person-month is equivalent to approximately 160 hours of labor, and is the amount of work performed by a single average worker in one month (ie. 12 person-month project will take 4 developers 3 months work to finish). A person-year is the total effort in person-months divided by twelve, to estimate the project length in years. .
Comparing Accessibility Checking plug-ins
When comparing like-for-like accessibility checkers across the various rich text editors, not all of their features are deemed to be equal. Here’s a comprehensive breakdown undertaken across all the accessibility checking capabilities of five popular editors, to see the one that works best for a specific use case: Under Pressure – Accessibility Checker
Comparing rich text editors
Choosing a rich text editor (RTE) to use within your SaaS product, web application, CMS, LMS, email marketing or internal workspace, isn’t a simple decision. Here’s comprehensive side-by-side comparison of key rich text editors (updated twice yearly):
TinyMCE Alternatives: WYSIWYG Editors Competitive Overview
Froala vs TinyMCE | Why TinyMCE is the Best Froala Alternative
TinyMCE vs Quill | Why TinyMCE is the Best Quill Alternative
TinyMCE vs Tiptap | Why TinyMCE is the Best Tiptap Alternative
TinyMCE vs Slate | Why TinyMCE is the Best Slate Alternative
TinyMCE vs CKEditor | Why TinyMCE is the Best CKEditor Alternative
Download the white paper:
The Great Debate: Buy vs. Build
Rich Text Editors
By completing and submitting the form you’ll receive information and tips from Tiny Technologies.