In my last post in the Digital Accessibility Maturity Model (DAMM) Series I detailed the Fiscal Management Dimension of DAMM. In this post I’ll discuss the Development Lifecycle Dimension, the aspects and artifacts associated with this dimension, and what each of the five maturity levels looks like for the this Dimension. (DAMM Definitions and Acronyms)
The Development Lifecycle Dimension measures the extent to which accessibility is included and defined in the development lifecycle activities of the organization. This includes all ICT covered by WCAG, including electronic files, websites, and mobile applications.
- Development Artifacts Creation Process – The maturity of the organization relating to specific development artifacts that must be developed and or filed with the Accessibility Program Office as part of the development lifecycle.
- Roles and Responsibilities – The maturity and definition of specific and effective roles and responsibilities related to accessibility in the development lifecycle.
- User Acceptance – The degree to which resulting products and services are accepted by users and deemed to be functionally usable by persons with disabilities.
- Pattern Library – The degree to which reusable, accessible user interface components are developed. This aspect looks at reuse of accessible code across the organization and leveraging consistent user design paradigms to implement accessibility as a sub-activity of consistent user interface design.
- Root Cause Analysis Process – The process definition associated with process improvement when accessibility defects are discovered post release. In a mature organization, this leads to a process improvement plan which helps reduce the chance of similar defects occurring in the future.
- Lifecycle Roles and Responsibilities – A definition of the roles and responsibilities organization units have in implementing accessibility in the development lifecycle.
- Accessibility Responsibility Breakdown (perhaps through a RACI diagram) provides more information on roles and responsibilities in the accessibility component of the development process.
- Development Artifact Guide – A list of the specific development artifacts lines of business must create and or file with the central Accessibility Program Office.
- Accessible Wireframe – A wireframe is an image or set of images which displays the functional elements of a website or page, and is typically used for planning a site’s structure and functionality.
- Storyboard – A sequence of drawings, typically with some directions and dialogue, representing the flow planned for a movie, television, software, or video on a website.
- Heuristic Evaluation – A usability inspection method for software development that helps to identify usability problems in the user interface design. It specifically involves evaluators examining the interface and judging its compliance with recognized usability principles (the “heuristics”).
- Workflow Scenarios – Orchestrated and repeated pattern of business activity enabled by the systematic organization of resources into processes that transform materials, provide services, or process information. This can be depicted as a sequence of operations, declared as work of a person or group, an organization of staff, or one or more simple or complex mechanisms.
- Process Improvement Plans – Plans resulting from trends, or post-release defects discovered to improve accessibility reliability going forward.
- Program Implementation Plan – Plan for how accessibility program is to be implemented in development lifecycle.
Level 1 – Initial
- Accessibility, if addressed at all, is included in the systems development lifecycle on a reactive and ad-hoc basis.
Level 2 – Managed
- Accessibility is defined as part of the organization development lifecycle, and requirements for specific stages are documented.
- Accessibility process and artifacts are documented for each major development lifecycle stage.
- Documented process includes addressing or reviewing potential accessibility issues at each phase of the process.
- Validation steps are present to ensure accessibility is met at each development stage or sprint.
- Relevant artifacts are completed and filed with the Accessibility Program Office (APO) or Line of Business (LoB) based on the governance model.
- Accessibility testing policy addresses the following issues:
- Developer unit testing;
- Testing with assistive tools;
- The need to have a diverse tester pool including end users;
- Functionality and content testing; and
- Defining the roles and responsibilities of everyone who performs a formal function in the testing process.
- There is a mechanism in place for involving persons with disabilities in all phases of the development process.
- Accessibility is reviewed for ICT which is acquired, rather developed in house.
- Accessibility is defined for each major stage of development:
- Quality Assurance; and
- Accessibility validation is performed at the transition steps between stages including system/user testing.
- Accessibility is clearly defined as part of the “Definition of Done” or the “Acceptance Criteria” for each backlog item.
- When remediating inaccessible systems, accessibility requirements may be defined as backlog items.
Level 3 – Defined
- Accessibility is fully integrated into the product development process and considered from end-to-end.
- Knowledge transfer occurs when project personnel leave projects or the organization.
- Accessibility sign-offs are included as standard requirement in all projects phases.
- Usability / Accessibility testing by is performed by persons with disabilities.
- Process in use, including accessibility / usability user acceptance testing.
- Recording and learning from the results of disabled staff and customer consultations / research findings.
- Records / examples of process in use including completed test scripts and non-conformance management.
- Records / examples of disabled users being identified, where appropriate, prior to implementation and any required action taken.
- Accessibility and personalization features are documented and persistent (e.g. do not have to be reset by user each day).
- Help, training materials etc. reflect use by disabled staff (e.g. no mouse-only instructions) and are provided in alternative formats when required (e.g. Braille).
- VPAT/GPATs for ICT which is acquired from vendors are reviewed and filed with the Accessibility Program Office.
Level 4 – Quantitatively Managed
- Development accessibility metrics have been defined, and are being actively collected throughout the process.
- Development metrics are reviewed, analyzed for trends, and provided to senior management to serve as input for ongoing employee assessments.
- Lessons learned / improvement process in place.
- Waterfall – Post release meeting.
- Agile – Incorporate into Sprint Review Meeting.
- ICT is compatible with and functionally usable in assistive technology.
- Post implementation accessibility reviews / user surveys are conducted.
- A feedback loop is in place to implement process improvements based on the results of these reviews/surveys.
- Development team takes a strategic and integrated, as opposed to a “silo” view, of implementing policies and standards (e.g. look at how all systems user needs to complete a task work together, look for new opportunities for disabled staff rather than just supporting existing users).
- Records / examples captured regarding how accessibility/usability issues are identified and addressed, multiple system view being taken, etc.
- Details of new accessibility concepts are captured, shared and re-used.
Level 5 – Optimizing
- Organization is going above and beyond stated policies and standards and innovating to meet functional needs of persons with disabilities.
- Innovative approaches to accessibility are shared via industry and trade groups.
- Active feedback loop with Accessibility Program Office on the implementation of aspects of the accessibility policy.
In my next post I’ll discuss Dimension #7 of DAMM – the Testing and Validation Dimension – which measures the degree of maturity associated with accessibility testing processes and approaches. This encompasses an evolution from a chaotic testing environment to active, structured testing, to a continuously updated testing approach that includes assistive technology and integrated testing by users with disabilities.