Role-based Analysis Update: WCAG 2.2
- This presentation is the third on role-based analysis of WCAG. ("Rethinking Accessibility: Role-Based Analysis of WCAG 2.0", CSUN 2017; "Role-Based Accessibility Update: WCAG 2.1 & More", CSUN 2019). This presentation will cover WCAG 2.2. Goal 1: Dispel the Myth of the Developer's Ownership of Accessibility Findings from these presentations continue to show accessibility is not something front-end developers can code into a digital product at the end of the software development lifecycle. Accessibility is directly impacted by other roles earlier in the process and does not require extensive accessibility knowledge and training. New in this presentation is tracking trends found through three versions. Goal 2: Do It Yourself To better understand the findings and apply them in their own organization's description of the methods and terminology is necessary and provided in the presentation. This also allows attendees to repeat the process and apply it in their work. Three questions are asked of each Level A and AA success criteria: 1. Who? Which roles make the decisions that affect conformance of the success criterion? 2. What? What type of knowledge do roles require to create accessible solutions? 3. When? At what stage in the software development lifecycle are these decisions made.? The first question ("Who?") uses a method similar to the RACI (or RASCI) Model for roles and responsibilities. It starts with five common decision-making roles that were identified and defined: 1. Business Owner 2. User Experience (UX) Designer 3. Visual Designer 4. Content Author 5. Front-end Developer Instead of 4 (or more) ownership levels, this method defines three: 1. Primary 2. Secondary 3. Contributor The second question defines the types of knowledge necessary to make decisions that conform to success criteria. Three types of knowledge or information were identified. A key factor is whether the necessary information is part of existing domain knowledge for the primary ownership role. 1. User Story / Standard Requirements 2. Domain Best Practices 3. Accessibility-specific Knowledge The last question defines common entry points or design documents used in the software design lifecycle. These are the key in a shift left strategy in identifying the earliest and most effective way to create accessible products. Six common lifecycle documents were identified and defined. The following list is sorted in approximate order of creation: 1. User Story / Requirements 2. Wireframes 3. Style Guides 4. Design Comps 5. Content 6. Code Accessibility issues can be introduced in many places. Similar to ownership levels, three levels were defined: 1. Primary 2. Secondary 3. Impact In the presentation, several different success criteria examples cover all roles, entry points, and types of knowledge. Additional information is also presented, such as the Accessibility Roles and Responsibilities Mappings (ARRM) project team of the Education and Outreach Working Group of the W3C Web Accessibility Initiative led by Denis Boudreau. Those beginning in accessibility can benefit from this presentation. Summaries of the methods are short, emphasizing the findings. Those findings should help all present stronger cases for shifting accessibility left in the product lifecycle. Those with deeper accessibility can apply the methods in their organization.
- Information & Communications Technology
- Research & Development
- Audience Level
- Session Summary (Abstract)
- Role-based analysis of the nine new WCAG 2.2 success criteria confirms the increasing need for – and the ability of – accessibility to “shift left.” Learn the new requirements content authors, user experience, and visual designers must conform to the new standard now and in the future.
- Session Type
- General Track
- Digital Accessibility
- Bill Tyler