View source for Ownership Assignments Variations With Design Phase

Parent document: https://www.w3.org/WAI/EO/wiki/ARRM_Project_-_Accessibility_Roles_and_Responsibilities_Mapping
<h2>Context</h2>
<p>For the purposes of this document the discussion of checkpoints assumes that an completed (or nearly complete) product is being tested. As a result, the assignments shown the examples tend more towards front-end developers than they might if reviewing design documents like style guides, wireframes, requirements, or content. Depending on the exact nature of the issue ownership might differ</p>

<h2>Ownership Variation Example</h2>
<h3>Checkpoint Example</h3>
<p>Checkpoint IMG-003 is "''Null alt attribute values are used for images that are already described in text in adjacent page content.''" Inherent in this test is identifying that the images "are already described." </p>

<h3>Design Phase Ownership (Requirements, Wireframes, etc.)</h3>

<p>In design phases the UX Designer, Visual Designer and Content Author are actively involved making all the decisions. This applies to the early steps in creating new site, design, features, pages or overall content. It reoccurs later with any additions or updates to the site.</p>

<p>Since there is no implementation the developer cannot a be a true primary owner, secondary owner or even contributor. The only situations the Developer is needed would be for technical questions about feasibility or support. One of the other roles would be the primary and work with one or more of the others to define how the image will be described in page content (such as a data table with the values shown in pie or bar chart.)</p>

<p>As experts in the intended deliverable the non-developer roles should document this. It might be explicitly stated in requirements. It might be covered less directly in general overall guidelines or standards. But ultimately in the design phases one of these roles would own the decision.</p>

<h3>Delivery Phase Ownership (Checkpoints)</h3>
<p>When testing an actual site (whether already delivered or in preparation for release) ownership tends to transfer to the developer in this case. The expectation is the developer should know that the image is decorative and implement it in a way that it is ignored by AT. Assuming the developer knew this, that role has primary ownership.</p>

<p>This is the clearest if the alt attribute was omitted entirely, had text left over from copying and pasting from another image, or the developer authored some text for the value. These are obviously coding issues. It is also easily assigned to the developer if there are explicit instructions or requirements that identify an image as "essentially decorative" and described in body copy.</p>

<h3>Missing Requirements and Contributor Roles</h3>
<p>The issue is less clear when there is no explicit requirement saying an image "decorative." If a developer has no guidance at all that role may assume that some simple text is necessary and add it. If there was some guidance the developer may interpret the situation differently than intended and provide alt text. Since design or authoring is not their specialty this is not unusual, especially in projects that have a lot of legal, corporate or other input.</p>
<p>This is where Secondary ownership and Contributors get involved. Roles that need to be available to provide a quick confirmation that the image is decorative should be Contributors. If the situation is not simple, requiring further investigation and review the role(s) involved should be Secondary owners. These discussions might even extend to include the accessibility expert to help the designers and author confirm the final outcome.</p>

<h3>Ownership Means Availability</h3>
<p>These "difficult" cases are exactly why multiple roles need to be available throughout a project. Designers and authors do not need to be allocated full-time to the project in the later phases respond to these situations. But neither should their roles be left unfilled for the developer, QA or accessibility tester to make their best guesses. For successful results the correct expertise is needed to ensure the final result is both accessible and meets all the other intended requirements.</p>

<h3>Value of Extended A11y Requirements</h3>
<p>As already discussed, to reduce the need and likelihood of checkpoints failing and requiring more input from Secondary and Contributor roles it is valuable design documents to clearly specify information needed for content to be accessible.</p>
<p>Information that can/should be documented includes:</p>
* Operation
** Keyboard
** Mouse
** Motion and Gesture (alternatives)
* Presentation
** Text and non-text contrast
** Keyboard focus
** Decoration
* All final copy or text to be used including
** Alt text for icons and controls
** Descriptions for all content images, including whether they are in body copy, alt text or a long description option
* Semantics
** Page elements and structure
*** Reading and tab order
*** Header / Main / Footer / Aside
*** Navigation
*** Custom component roles for menus, tabs, accordions, carousels, sliders, etc.
** Content sections
*** Page title
*** Content headings and their nesting
*** Lists
** Forms, Fields and Error Handling
*** Fields related labels
*** Instructions and data format requirements
*** Field groupings
*** Error message reporting, updating

<p>The amount documentation detail needed typically increases with the more the design differs from browser or typical site presentation and operation. A site with no CSS and elements that easily map to semantic HTML may need little or no additional documentation. Single-page applications or those with numerous custom components will need considerable support documentation to implement correctly.</p>