What is Agile?
Agile refers to a broad set of concepts that share the same four common values (from http://agilemanifesto.org/):
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Accessibility should run throughout the agile scrum process
The twelve principles of Agile (http://agilemanifesto.org/principles.html) have led to various interpretations with application in a number of models, including those focused more on practices (e.g., Extreme Programming), those focused more on work flow (e.g., Scrum and Kanban), as well as a number of hybrids and combinations. The approach described below relies mostly on the Scrum approach (one of the most common models), to illustrate how accessibility practices should fit within Agile. Many of the same principles can be applied to other models of Agile.
The Agile Approach to Accessibility
Accessibility as an integral part of Agile development
As depicted in Figure 1, a product is built in constrained increments of time known as sprints in Agile. A sprint is typically two to four weeks. Prior to initiating a product build, all requirements are added to a Product Backlog. When planning for a sprint, a subset of these requirements is moved to what is known as a Sprint Backlog. These requirements are then used to build a product increment within the sprint. These products may be “done” (ready to provide to an end– user) – or not (requiring additional work in another sprint). Daily scrum meetings are conducted to assist the development team in collectively building the product increment within the sprint.
An effective Agile approach to developing accessible software and web content starts with the fundamental understanding that an application or website must be functional and usable for all users, regardless of ability. Accessibility is a habitual expectation that all development team members accept as part of the normal course of work. Naturally, adequate training is necessary for developers to know how to write code that is accessible and conforms to accessibility standards. Likewise, testers must be able to follow a standard test process to reliably validate conformance and overall accessibility.
Key accessibility integration points within the Scrum process include:
- The development team has knowledge of accessibility standards and test processes and access to accessibility expertise for consultation and validation at key milestones.
- Iterative development and testing includes developing functionalities that work for all users, including those with disabilities, and testing to validate conformance to accessibility standards.
- The “definition of done” for all product increments must include conformance to accessibility standards.
The sections below further describe other key elements of accessibility in Agile development:
Include conformance to accessibility standards in the “definition of done”
Agile development teams must form a shared understanding of what it means for work to be complete. The “definition of done” can vary significantly from one development team to another, depending on client or product owner requirements, development team preferences, and the environment. All product increments must conform to Section 508 standards in order to be considered “done.”
Incorporate accessibility standards in key artifacts
Regardless of an organization’s specific software development methodology, ICT accessibility must be included, at a minimum, in all key artifacts.
• Requirements: Whether described as elements of a Product Backlog, System-Wide Specifications, or other designation of requirements, the development team must establish accessibility standards as technical requirements for its ICT development.
o Each Agile team determines the best method to document these requirements for the team. Some teams include accessibility requirements in acceptance criteria, as separate user stories, or in other ways.
o Whatever the documentation method, the team must understand the necessity for incorporating accessibility in requirements.
o As with other system requirements, teams should identify any deficiencies in the team’s knowledge, skills and abilities to implement accessibility requirements early in the process in order to better identify solutions to meet the accessibility requirements (e.g., training, hiring or subcontracting to an IT accessibility resource, working with an agency’s Section 508 office, etc.)
• Design and Architecture: Conformance to accessibility standards influence design and architecture decisions, whether it relates to choices about specific types of technologies or user interface (UI) design considerations. The development team must include accessibility standards conformance in the earliest stages of design and architecture to promote the ability to conform to the standards in the subsequent development of the application.
o User experience (UX) designers must address all requirements (including those for accessibility) when developing wireframes and visuals.
o Strong UX designers typically have experience or education in designing to include elements that are universally usable – meaning that they are designed for all user types, including those with disabilities.
• Test Plans: A standardized accessibility test process for ICT content informs test planning, serving as elements of test scripts and describing the specific processes necessary to validate that “working software” really will work for all users.
Minimize subjectivity by following a standard accessibility test process
A development team should adopt and implement a standard test process for each application and for all features or functions of ICT to avoid confusion and minimize subjectivity in validating conformance to accessibility standards. Documenting the standard test process and following the applicable test procedures throughout iterative development establishes a common understanding of accessibility requirements and helps improve confidence that the ICT conforms to the standards before it moves to production.
Using Test-Driven Development and automated testing in Agile accessibility
The concept of Test-Driven Development (TDD) is one of the common hallmarks of Agile methodologies. In a nutshell, TDD requires writing tests to validate that functional and technical requirements are met before actually writing any code.
Writing the tests before writing code encourages developers to focus more acutely on requirements before shifting focus to develop features. The process also tends to produce simpler designs as it discourages developers from developing code outside of the scope of requirements (only write tests that validate requirements, and only write code sufficient to pass the tests). Assuming that accessibility is incorporated within requirements, TDD likewise requires understanding the accessibility requirements in order to write tests to validate that specific interface elements and content conforms to the requirements as they are developed.
Certain forms of TDD often make use of automated testing tools to facilitate code validation and increase the volume of tests that can be performed. A number of automated testing tools exist with rulesets devised to evaluate conformance with many of the WCAG 2.0 Success Criteria. Such tools can drastically decrease the time necessary to write and perform tests while improving the ability to identify flaws. However, in many cases, whether related to accessibility requirements or other functional requirements, some evaluations still require human cognition to determine whether certain features meet the requirements.
Given the automated testing tools currently available and the nature of some of the WCAG 2.0 Success Criteria, no amount of automated testing can completely eliminate the requirement for manual inspection of certain ICT content. Therefore, even high-functioning teams effectively using automated testing will require strong familiarity with accessibility in order to incorporate manual tests to evaluate conformance with all of the accessibility requirements.
Provide Section 508 subject matter expertise
Developers should be able to build accessible ICT and testers should be experienced in validating that it conforms to accessibility standards. Nevertheless, it may still be necessary to consult subject matter experts to confirm conformance or nonconformance to standards, help troubleshoot and remediate issues and evaluate the risks associated with non-conformant work products.
Experienced members of the development team may serve as accessibility subject matter experts, or the development team may need to rely on subject matter experts external to the team. Each development team should identify, based on the overall skills and experience of the team, how to distribute the time and attention of the accessibility subject matter experts throughout the development process to assist when necessary and promote full compliance with accessibility standards.
Major Differences Between Agile and Waterfall Development
This paper does not seek to promote Agile over traditional waterfall development. Like waterfall, Agile also has distinct benefits and drawbacks. IT accessibility practitioners, Section 508 Coordinators, and Program Managers can take better advantage of benefits and mitigate drawbacks to promote accessibility by understanding them.
Benefits of traditional waterfall development
Benefits of Waterfall: Accessibility Implications
|
Well-defined milestones and deadlines |
|
Standardized documentation
• Facilitates location of accessibility-related information in standard process and system documentation (e.g., requirements, test plans, milestone reviews)
• Helps facilitate governance and review of conformance at milestones via documentation of conformance assessments
Drawbacks of traditional waterfall development
Drawbacks of Waterfall: Accessibility Implications
|
Difficult, costly change |
|
Slow delivery and subsequent release schedules
• Because waterfall development projects tend to deliver entire collections of identified features and functionalities in a single production release, accessibility issues identified for remediation are typically grouped with similarly large collections of enhancements or modifications targeted for subsequent releases
• Accessibility defects tend to have longer lifespans while awaiting the next release to include fixes to address the accessibility issues
Benefits of Agile:Immediate user feedback
Accessibility Implications
• Because Agile projects release functionality in small increments, users, including those with disabilities, begin to use the functions and features earlier in development and can provide feedback to developers
• Agile teams can identify and remediate accessibility issues in early development rather than perpetuating the defects throughout later stages of development
|
Adaptability |
• Shorter development cycles with smaller, incremental iterations of functionality provide the ability to reprioritize requirements to respond to evolving project objectives, including the ability to prioritize accessibility issues when identified |
|
Quicker delivery and shorter release timelines |
|
Drawbacks of Agile:Accessibility Implications
|
Ambiguous timelines |
|
Dependence on team’s skills
• Because agile teams tend to be smaller (4-9 developers/testers), some team members may need to perform more than one role, and not every team member may have specific knowledge of accessibility best practices
• Accessibility subject matter expertise can become spread thin, especially across Agile teams; naturally, training for all team members to familiarize them with accessibility requirements can mitigate the need for consultation with accessibility subject matter experts
|
Neglect of documentation |
• While organizations may still enforce documentation requirements, and Agile development does not preclude robust documentation, the ideology nevertheless focuses on functioning work products over documentation; inadequate documentation of accessibility requirements and test procedures can lead to inadequate incorporation and validation of accessibility |
Keys to Success in Implementing Agile Accessibility
To summarize, incorporating accessibility in Agile development methods will succeed when development teams view accessibility as an integral part of the process throughout the entire development lifecycle.
Key points of integration to successfully promote accessibility in Agile development:
- Include accessibility conformance in the “definition of done”
- Incorporate accessibility standards in key artifacts
- Minimize subjectivity by following a standard accessibility test process
- Follow TDD practices
- Provide Section 508 subject matter expertise to development teams, and ensure that all team members have adequate knowledge of accessibility requirements