Role-Based Decision Tree (old)

Context

The role-based decision tree is a framework to help anyone define an accessibility matrix of their own within their organization. It is a process to help teams define and distribute ownership and responsibility of accessibility requirements in the project lifecycle. Using this framework, a team should more easily define who ultimately own specific requirements, who else is actively involved, those that contribute to the successful implementation of the taskpoints in the lifecycle.

Ownership levels

The framework defines three levels of ownership for accessibility requirements, based on commonly agreed upon RACI matrix principles:

1. Primary
2. Secondary
3. Impact

RACI Responsibility Roles and Accessibility Ownership Levels

Similarities

Ownership role levels are very similar to the RACI responsibility roles. For those familiar with RACI definitions these can be helpful in understanding ownership levels but are not necessary. RACI responsibility roles can be mapped to ownership levels like this:

RACI Role to Ownership Level Mapping

• Accountable -> Primary
• Responsible -> All Ownership Levels
• Consulted -> Contributor
• Informed -> All Ownership Levels (Unnecessary)

Differences

All Owners are "Responsible"

A key difference in the between models is the idea of "active" participant in the decision making process. In the RACI model, all ownership roles used in this process would be "Responsible" since they are actively involved in some way. This is why there are some mappings that are not one-to-one.

"Responsible" Owners are Inherently "Informed"

Another difference with the RACI model treating all owners as "Responsible" is that being simply "Informed" is not active participation. Decision-making roles inherently require some active involvement, not just notification of outcomes. This also means all ownership levels, by being responsible, are inherently "informed" of outcomes. As a result the RACI "Informed" roles are not part of the role-based process.

Role Ownership Definitions

Primary Ownership = "Accountable"

Primary ownership aligns most closely with with "Accountable" (or "Approver" or "final approving authority") in a RACI matrix.

Primary owners typically:

• Drive the decision-making process
• Have direct interaction with the secondary owner(s) discussing issues
• Delegate the work to other roles or team members (as needed)
• Lead the task to completion
• Have final sign-off authority (if/when used)
• Are ultimately accountable for the outcome of taskpoint or design decisions

The last few points emphasize that the primary role is ultimately accountable. This is why there can only be one primary owner for each taskpoint.

Secondary Ownership = "Responsible"

The Secondary role most directly aligns with the RACI matrix "Responsible" (or "Recommender"). Unlike RACI, and since Primary owners are also responsible, there can be cases where there are no Secondary owners.

Secondary owners:

• Directly support the primary owner
• Are actively involved in the decision-making process
• Have active interest and participation in the outcomes
• May work to complete the task
• (but) Ultimately defer final decisions to primary owner

Contributor = "Consulted"

The Contributor role typically aligns with "Consulted" (or "Consultant" or "counsel") in a RACI matrix. In this model, the interaction from a Contributor is typically one-way, but could be two-way as in RACI. Like Secondary ownership, there are often taskpoints with no Contributors.

Contributors:

• Are not actively involved in the decision-making process
• Typically provide initial input or requirements
• May be asked to provide additional information

Contributors may have only limited participation by providing initial design input (such as branding guidelines or business requirements) with little or no subsequent interaction. In those cases the communication may be input only with little or no concern of being "informed" of the result (relying on the expertise of other owners).

Business

Business roles

Business Analyst as Secondary Owner

Business Analysts are not typically active as a secondary owner in most taskpoints. This role might be a secondary owner if there are active discussions that need review and approval for changes to items dictated by business, requirements, variation to branding guidelines, core features and high-level product functionality, or contractual or legal requirements and review. After initiating the project the role is typically hands-off.

Business Analyst as Contributor

In practice business typically more of an impact role so it is not unusual for the

UX Design

UX Design is often involved with most taskpoints since the role is integral to the overall design and function of a site. UX Designers are likely to be a secondary owner in cases where taskpoints involve or impact:

• The overall operation of the site, features or general operation including:
  • General site structure
  • Main navigation
  • Components to be used
  • User interactions - including keyboard, mouse, touch, gestures, motion
  • Use of color, text, icons, graphics in the abstract requirements, not final selection
• The general definition, operation or structure of individual pages, components or features including:
  • General layout of forms, fields, labels, instructions and error handling requirements
  • Approaches for providing text alternatives for major elements such as complex graphics
  • General component definition and requirements for structure, operation and interaction
  • Use of color, text, icons, graphics in the abstract requirements, not final selection

UX Designer as Secondary Owner

As a secondary owner the UX Designer may be needed by the primary owner to answer questions about the intended use or purpose of items in the requirements, specifications, user stories or other documentation provided. Since UX Designers (by definition) oversee the entire design they are likely to want to review any decisions that may affect the final experience. They are unlikely to be involved in lower level selection of colors, specific text or implementation details.

UX Designer as Impact Owner

The UX Designer role is often a primary or secondary owner since they typically oversee the overall design and structure of the site. As a result they are usually need to be actively involved in many, if not most, decisions to ensure the final design meets the intended goals. It is rarer for them to only need to be informed or lower level decisions. This typically happens in cases where the taskpoint deals with something that is fully owned by other roles.

An example where this often comes up is the video content. The UX Designer will be critical to defining the page structure and features of the video player. But the content is typically handled by other roles and well beyond the UX Designer's ability to impact or change. The UX Designer will want to know that video has captions, transcript and is accessible but typically is not involved in its creation, editing and updating.

Visual Design

Visual Design is involved with the final presentation design choices. Visual Designers are likely to be a secondary owner in cases where taskpoints involve or impact:

• Final color and font selection
• Final Layout
• Delivered graphic elements including:
  • Icons, sprites and glyphs
  • Content images, including graphic text
  • Background and decorative imagery

Visual Designer as Secondary Owner

The Visual Designer is typically a primary owner of the final presentation issues or informed about any variations to their work. It's rarer for them them to be a secondary owner. This typically occurs when the UX Designer is the primary owner but needs considerable input from the visual designer.

Visual Designer as Impact Owner

A Visual Designer is likely to want to know the outcomes of decisions that impact the final presentation when they are not the primary owner. Examples of this are when simple text or operation changes lead to cases not be clearly covered in style guides or comps.

Content Authoring

Content Authors are involved any time there is text or text-based content (such as the spoken part of a video or audio media). Content Authors are likely to be a secondary owner in cases where taskpoints involve or impact:

• Control and field labels
• Link and menu text
• Headings, paragraphs and body copy
• Audio and visual content including:
  • Captioning
  • Scripts or transcripts
  • Descriptive audio
  • Translations

Content Author as Secondary Owner

As already mentioned, Content Authors are typically a secondary owner anywhere there is any text.

Content Author as Impact Owner

When not a primary or secondary owner, Content Authors are usually not involved. The few cases where they might be an impact owner and need to be informed about decisions are in taskpoints where the management or presentation of text changes.

Development

Discussion of Developer ownership frequency

Developers are likely to be a secondary owner in cases where taskpoints involve or impact:

• Selection of implementation method
• Choice of support libraries and code for implementation (including creating new custom elements)
• Technical details and especially limitations directly impacting presentation, content or operation

Developer as Secondary Owner

In early design phases Developers are most likely to be secondary owners working with the primary to identify what is possible to implement (when the requirements are vague or challenging). In testing and remediation work this situation may reoccur where the primary owner needs to work with Development to identify which implementations are possible to make a final decision. As a result it's not uncommon for the Developer role to be a secondary owner.

Developer as Impact Owner

Since Developers are so integral to the final delivered product they are typically primary and secondary owners. There are fewer cases where the Developer is an impact owner. These cases are where a decision may require additional information beyond the standard updated requirements, user stories or specifications.

Accurate Developer Involvement in Decision Making

Developers could be considered actively involved in the delivery of all taskpoints since they are integral to the final product. This is where the distinction about design decisions is important. Issues that deal with selection of colors, general layout and presentation, content used, or high-level features have little or no direct code implementation concerns are common. Such cases represent situations where developers may not be a true owner at all since their roles is simply to ensure the decision is implemented as specified by the active roles. As a result, it is rare for the Developer to be a secondary or contributor unless the primary owner needs active technical input to make a decision.This also applies to simply fixing bugs in the implementation.

Development Ownership vs. Bugs

Though it is true that the final site is always dependent on the implementation, in this exercise it's important to differentiate between incorrect implementation (bugs) and active participation in the decision making process or design. If the developer correctly implements the requirements, design specs or other details provided and the result is not accessible (such as inadequate contrast, missing skip links, missing error detection or reporting) this is an issue with the design. The issues are owned by the roles who (should have) provided the developer with the requirements that did not account for accessibility - especially when they have functional, presentation, or content dependencies.

If the requirements and documentation have accessibility concerns correctly addressed and the resulting implementation doesn't match - that is really "just a bug" or an incorrect implementation. It should be treated as any other inconsistency or mismatch between specifications and delivered result. A simple example would be color contrast errors where the correct color codes were provided in a style guide but not correctly entered into CSS classes.

Tester (very rough draft)

Distribution discussion goes here

Testers are like to to be a secondary owner in cases where taskpoints involve or impact:

• Testing tool capabilities
• Testing protocols
• Changes to the details needed by tester to complete

Tester as Secondary Owner

As mentioned in the primary ownership decision tree, Testers are not typically part of the design process. This extends to secondary ownership where secondary ownership might apply if testing is tightly integrated into the design process.

Tester as Impact Owner

Testers may make a good candidate for Impact ownership since, like developers, they are involved with all aspects of the deliverable. Also like development, the need to have additional accessibility ownership notification beyond normal updates is likely to depend on the completeness of the updated requirements and specifications. If the details affecting accessibility are fully defined with all other requirements they are likely to be simple additional "line items" to test and not require added input to the tester.