Learn how and where web accessibility fits into a different development cycles, and how automated systems can help any organization achieve a higher level of accessibility.

Web Accessibility, which refers to the inclusive practice of removing barriers that prevent individuals with disabilities from accessing and interacting with online content, is a growing topic among many companies. Aside from a moral responsibility, companies are slowly being required to ensure that their online presence is accessible to all individuals, including the disabled. According to the Global Legal Post, web accessibility is the emerging litigation threat to US companies in 2016. This post will focus on where and how web accessibility can fit within a company’s development cycle, whether it be an iterative waterfall, collaborative agile, or some other system.

Case Study

Consider the example of a large corporation, Corporation X, which undertakes many web development initiatives. Corporation X is constantly developing new apps to enable rapid customer support and expending significant resources to maintain legacy web applications. Corporation X has decided to adopt Agile Development Methodologies to become more efficient and responsive to the needs of the market. In a corporation the size of X, an agile development team typically consists of web developers, graphic designers, user experience designers, system administrators, and quality assurance engineers. All roles play critical parts of any agile development effort, regardless of what specifics are implemented under the agile umbrella. But where does Web Accessibility fit into the existing Agile development cycles?

Method 1: Iterative Waterfall

Some Agile teams have effectively shortened the waterfall approach, a sequential design process, due to organizational constraints. While Agile Development experts say that this is not the preferred method, described as an “iterative-waterfall approach,” organizational needs and interdependencies frequently require teams to operate in this manner. There is still significant efficiency when creating a mini-waterfall approach on legacy teams, including shorter time to market, cost management, and a more effective harmonization with other Agile teams.

When Accessibility is incorporated into an Iterative Waterfall process, either an entire sprint or version release is typically dedicated to adding Accessibility features to an existing application component. For example, Figure 1 shows how the Program Manager determines an entire logical component of a website, in this case the home page, and directs his or her resources to bring the site’s experience into compliance with the standards and practices set fourth under the Web Content Accessibility Guidelines (WCAG). An Accessibility Expert then typically verifies these results before being approved and promoted to the production environment.

blog pic 1


Figure 1 – WCAG Development Tested in a “Mini Waterfall” Development Approach


This method, while effective with well-trained teams, can create a significant lag between the delivery of new capabilities and their Accessibility due to the larger time in-between functional releases inherent in Waterfall methods. As a result, the business needs that have pushed so many organizations to agile development in the first place (i.e., rapid market response) may get in the way of the timelines required to get Accessibility into place.

For the purposes of this study, rates and calculations were tabulated for Iterative Waterfall as follows:

Resource TypeRateFTEs
Subject Matter Expert$300/hr1
UX Designer$165/hr4
User Interface Specialist$100/hr10
Software Developer$180/hr12
System Administrator$120/hr5
Quality Assurance $100/hr10
Accessibility Expert$250/hr4

Figure 2 – Rates and FTEs for Iterative Waterfall

*Rates were derived from several cost studies from User1st customers and industry leading experts in accessibility supporting development initiatives. Each “Iterative Sprint” is 2 working weeks (80 working hours).

Given the high cost associated with Accessibility, most firms are not faulted for this approach, or the lag that results, but everybody wishes there was a better way.

Method 2: Collaborative Agile

In a more traditional agile environment, collaboration is a central aspect of the Sprint approach. The Product Manager (PM) oversees task management and alignment of resources, while teams focusing on User Interface (UI), User Experience (UX), and Development resources work side by side. As depicted in Figure 2, adding Accessibility to this model is straightforward; teams simply put an Accessibility Expert as an embedded Agile Team Member, which promotes “getting it right the first time.”

blog pic 2


Figure 3 – Accessibility Experts Embedded in an Agile Sprint


The rates and calculations for Collaborative Agile are listed in Figure 10 below. One major difference to note is the relatively flat number of FTEs by comparison to Waterfall methods, which typically require a much larger team.

Resource TypeRateFTEs
Subject Matter Expert$300/hr1
UX Designer$165/hr2
User Interface Specialist$100/hr6
Software Developer$180/hr6
System Administrator$120/hr5
Quality Assurance $100/hr5
Accessibility Expert$250/hr2

Figure 4 – Rates and FTEs for Collaborative Agile

Which Method is Right for Me?

The tradeoff between these development methods and the associated impact of incorporating Accessibility can be studied at length. But the central question is: Which method is more cost effective for adding Accessibility to my development process? Many organizational, technical, and political factors drive the decision of which Agile method an organization or particular project team will use. That said, the impact on Accessibility cost and time to market is necessarily tied to the method selected, as depicted in Figures 3 and 4.

blog pic 3


Figure 5 – Agile Method Cost Comparison per Release

blog pic 4Figure 6 – Agile Method Total Cost Comparison 

As shown in Figures 3 and 4, the total cost of Mini Waterfall is slightly lower than Collaborative Agile, but it delivers slower time to market—particularly for Accessibility features—and needs perfectly gathered requirements to maintain cost effectiveness. By comparison, Collaborative Agility costs more per release but allows 5 releases to occur in the same time that Mini-Waterfall completes only 3 releases, all with Accessibility features enabled at the time of release. So, while the cost of Accessibility is about 10% higher in a Collaborative Agility Team than in an Iterative-Waterfall approach, Accessibility accounts for 22% of the total development costs under Collaborative Agility, compared with 32% of under the Mini Waterfall approach. Regardless of which development approach is implemented, achieving Accessibility is expensive, resource intensive, and can have serious implications on overall timeline to get solutions to market.

Automated Systems Applied to Agile Development Teams

Since automated systems allow you to overlay on top of your existing website code, one would wonder: How do I incorporate automation into an Agile Development Cycle? No matter how your development cycle goes, the use of automation provides speed and agility in enabling Accessibility of your website. Take for example the following template Agile process:

blog pic 5Figure 7 – Automation as part of Agile Process

This collaborative agile process is very similar to those detailed in the earlier case study above. This graphic however provides a perfect example of how automation can be inserted into integration and test phases versus development phases of your Solution Development Life Cycle. This key distinction is possible because of the reduced time and simplified skillset required to operate an automated system. By putting an automated editor in the hands of the Technical Business Analysts that already take part in your Quality Assurance Processes, Accessibility becomes a function of the testing and quality assurance versus a function of engineering that is verified by testing. This reduces time and cost by reducing the resources needed to administer Accessibility, as well as shortening the number of resources needed to make a change. In other words: instead of having Accessibility development requiring access to UI, UX, and Development resources, this functionality can be centralized to a single Technical Business Analyst using an overlay system, allowing the same work to be done more quickly and without impacting the code-base. Please review the same case study as above using automation instead of traditional development techniques:

blog pic 6


Figure 8 – Agile Method Cost Comparison (with Automation)
blog pic 7

Figure 9 – Agile Method Total Cost Comparison (with Automation)


Under normal circumstances, achieving web Accessibility is anything but simple. Successful adoption necessitates research, committees, executive buy-in, risk-analysis, technical know-how, competent personnel, specialized training, third parties to assist if necessary, and a sound implementation plan. The process itself may take years to re-code, fix and amend sites to meet the recommendations of WCAG 2.0 AA. Time, however, is not the only factor an organization must consider when attempting to achieve accessible online content; cost is a fundamental and, in many instances, limiting factor to achieving web Accessibility.

Whether an organization finds a Collaborative Agile system, Waterfall system, or entirely different solution development process best meets its needs, the time and money needed to implement accessible web pages is significant. This is due to the fact that current strategies for achieving Accessibility necessarily rely on many resources (many times even an entire team) to execute the necessary changes. Automation systems are an innovative approach to web Accessibility that removes a large portion of the grunt work, while still achieving the same or higher level of compliance than slower and more expensive methods.