Regardless of whether you use contractors or agency staff to develop digital services and technology, Section 508 compliance needs to be addressed. Whether using waterfall, agile, or any other development approach, achievement of Section 508 compliance is dependent upon your ability to incorporate accessibility needs from the very beginning of the development effort (conceptualization and planning) and on through design, development, testing, deployment, continuous enhancements, and maintenance activities. Failure to consider Section 508 compliance throughout development will likely relegate 508 conformance considerations to the end of the project, when it costs the most to fix accessibility problems.
Key Questions
- How does your agency incorporate Section 508 requirements into your development processes (life cycles) used to design, develop, deploy and maintain digital services and technology solutions?
- When using agile processes, how do you ensure Section 508 compliance is addressed in each Sprint?
- How do you train and equip developers to ensure Section 508 compliance?
Checklist
- Address accessibility needs in project planning:
- Consider accessibility needs investment management and enterprise architecture decisions.
- Determine if development platforms, tools, hosting environments, and electronic content viewers could potentially create accessibility barriers for disabled users.
- Allocate funding to address accessibility assurance activities.
- Allocate time in your project schedule to allow for Section 508 planning design, testing and remediation.
- Address accessibility needs during requirements gathering and design (see Play 8 for more information):
- Conduct user centered design activities to identify disabled user needs.
- Identify applicable Section 508 standards for solution features and electronic content.
- Factor accessibility needs into solution design and alternatives assessments.
- Address disabled user needs and applicable Section 508 standards in initial design, pilot and proof of concept efforts.
- Address pre-existing accessibility issues when prioritizing technology enhancements.
- Validate solution designs and prototypes with disabled users.
- When using agile methods, ensure Section 508 conformance requirements are included in the “definition of done” for user stories that support development of a user interface/feature. If you do not factor a Section 508 conformance assessment into the determination of when each development sprint is complete, accessibility barriers may slip through and compound over time.
- Address accessibility needs during development:
- Train developers to understand the rationale and importance of Section 508 standards conformance and inclusive access.
- Provide Section 508 compliance testing tools to assist developers with performing unit testing, and provide training on how to use these tools to generate accessible solutions.
- Encourage the use of accessible code libraries.
- When using open source development platforms ensure responsibility for fixing accessibility issues is clearly determined.
- Address accessibility needs during testing (see play 10 for more information):
- Determine what accessibility testing methods you will use (recommend using test processes endorsed by the Federal CIO Council Accessibility Community of Practice)
- When using agile methods, ensure accessibility requirements are validated in unit tests.
- Identify where accessibility issues are located, and troubleshoot potential root causes.
- Implement processes and tools to track accessibility bug fixes and their resolution status.
- During deployment and maintenance:
- Ensure configuration and integration activities do not introduce new accessibility barriers.
- Monitor and validate updates to the technology solution to ensure they will not negatively affect accessibility.
- Monitor and validate changes to the technology environment will not negatively affect accessibility (operating system, browser, hosting platform, etc.).
- Include IT accessibility subject matter experts as authoritative decision makers at critical development checkpoints.
