Frequently Asked Questions (FAQ)

Frequently Asked Questions

Selecting No Additional Ownership Levels

Ownership assignment does not mean that all roles are involved on every checkpoint. Unlike primary owners, secondary owners and contributors can oftentimes be optional. It is common for there to be no secondary owners or contributors, especially in situations where the task is very specific. These are cases where the primary owner is the sole active role (such as choice of words for Content Authors, or color selection for Visual Designers). There are also situations where there could be one or multiple secondary owners, but no contributors. There are cases where the opposite may be true (no secondary but one or more contributors), though this is potentially rarer. Role ownership should only be added when their input is typically needed to effectively make final decisions on typical issues.

Additional Guidance Assigning Front-End Developer Role

Of all the roles in this process Front-End Developer can be the most difficult to assign properly. Here are is some additional guidance to correctly assign ownership to avoid the common mistake of overstating or overestimating the ownership of developers.

Development ≠ Ownership

Since the final deliverable is always dependent on its implementation it may seem appropriate to include the role as an owner on all checkpoints. This does not accurately reflect development with regard to decisions that impact accessibility in ARRM. For this process, it’s critical to differentiate between design decisions and details provided (or delivered) to developers from those where they actively participate in making or deciding.

No Input = No Ownership

If developers are given requirements to which they had little or no input they cannot be held accountable for results when implemented “as designed.” In many cases if they did not implement the requirements as written it might be reported as a bug even it if improved accessibility.

Scale & Scope of Contribution Matters

If developers are actively involved in design decisions that define the final requirements they are more likely to be an owner. But even in these cases the level of ownership is directly related to how their input impacts accessibility. Developer ownership level increases with directly with how their input impacts accessibility and where it applies.

Developers are typically involved actively in the functional and operational parts of a feature that impact page implementation. In these cases their ownership level rises with the amount and importance of their input to the final requirements and how they impact accessibility. These decisions include selecting infrastructure or approaches used. Accessibility topics in the Robust principle are one area where developers will have significant, often primary ownership.

Even when developers are involved there are portions where their input (and ownership) may be limited (Contributor at best or none) such as with UX or presentation. A developer cannot be held accountable for implementing colors that have inadequate contrast if they were specifically defined by designers. They should not take ownership for using instructions based upon sensory characteristics provided by a content author if they only coded the means to display the text.

Fixing Bugs is Not Necessarily Ownership

Another misunderstanding is to consider implementation errors (bugs) as indicating ownership. If the requirements and documentation correctly incorporate accessibility but are not correctly implemented they are really “just bugs” or incorrect implementations. The developer needs to correct the implementation as they would any other bug. Correcting bugs does not equal ownership. 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.

Coding Decisions = Ownership

Developers will be owners, often primary owners, when the issue is specifically about implementation or coding. If requirements leave the final implementation to the developer’s discretion and it’s is not accessible then it’s likely owned by that role. A simple example would be where images are marked as decorative in the requirements but the developer implements them so they are announced (such as without alt=””). Another is leaving out region definitions of page in HTML5 or ARIA, or heading tags that were included in the definition of the page structure.