WAI/ARIA APG Redesign/

Purpose

Many W3C resources include similar and overlapping content that aim to help web developers effectively implement accessibility standards. Several are listed in the scope of the WAI/WCAG support documents redesign project.

This Authoring Practices Guide (APG) Redesign project proposes a multi-year, multi-phase plan to redesign, harmonize, and integrate several of the primarily engineering-focused accessibility resources, starting with the WAI-ARIA Authoring Practices. It is designed to complement the WAI/WCAG support documents redesign project and accelerate its objectives of making W3C accessibility support materials easier to discover, navigate, and apply to web projects.

Problem statement

1. Because the WAI-ARIA Authoring Practices Guide (APG) is a monolithic W3C Note that is published in TR:

   1. APG is unnecessarily difficult for readers to consume and reference.

   2. Updates and maintenance are overly complex.

   3. Out of date versions are surfaced by search engines.

   4. Making content embeddable on other sites, such as MDN, is not feasible.

2. Similar accessibility resources targeting the same audiences:

   1. Are sometimes redundant and sometimes conflicting, creating reader confusion.

   2. Rarely sufficiently cross-reference each other, reducing findability and causing readers to overlook relevant information.

   3. Sub optimize the human resources we have available for producing and maintaining accessibility resources.

Objectives

1. Improve APG clarity and usability, e.g., better information architecture, cleaner look and feel, ability to reference any section, eliminate versioning.

2. Increase findability of APG content, e.g., integrate into WAI site, surface content on MDN.

3. Increase utility and effectiveness of web engineering focused accessibility resources by:

   1. Harmonizing and integrating similar and complementary resources, e.g., APG, WAI tutorials, Using ARIA.

   2. Integrating assistive technology support data from ARIA-AT.

4. Improve currency and freshness of accessibility resources by:

   1. Organizing human resources around fewer deliverables.

   2. Increasing efficiency and reducing maintenance and publication complexity.

Note: As WAI technical accessibility resources evolve, it is essential to maintain the mission of supporting the ARIA Working Group specification development process with reference implementations and guidance for features in development.

Scope and Audience

The precise scope is TBD based on discussions with stakeholders and could grow significantly over time. The intent is to start with the most technical resources focused on serving web application, assistive technology, and browser developers. The most obvious choices in priority order are:

1. ARIA Authoring Practices
2. Assistive technology support data from ARIA-AT
3. WAI Tutorials
4. Using ARIA
5. Tips for Developing

High-level execution plan

This plan is structured to make incremental changes that are both simple for users to understand and easy for W3C staff and participants to make. The plan assumes execution of appropriate user research and impact analysis during each phase to inform planning of subsequent phases.

1. Phase 1 - Move APG from TR to WAI site:

   1. Placed in navigation adjacent to tutorials.

   2. Managed from its own repository, similar to tutorials.

   3. Minimal changes to structure and content.

   4. Light-weight integration of ARIA-AT data.

   5. Primary goals: Make foundational infrastructure changes, simplify publication, and remove need to version.

2. Phase 2 - APG presentation redesign:

   1. New, simpler, extensible information architecture.

   2. Improve usability, e.g., look and feel, search, indexes, etc.

   3. Complete ARIA-AT data integration.

   4. Content structure that facilitates embedding in MDN.

   5. Primary goals: Improve usability and establish foundation for increased scope, integrations, and rebranding.

3. Phase 3 - Tutorial harmonization:

   1. Add pattern examples that minimize ARIA utilization.

   2. Update tutorials to ensure currency (minimize content changes).

   3. Integrate or cross-reference tutorials (TBD).

   4. Rebrand to reflect broader scope.

4. Phase 4 –Using ARIA Integration:

   1. Identify and integrate content from Using ARIA that is not redundant.

   2. Stub using ARIA and build appropriate redirects.

5. Phase 5 – Evaluate and plan additional harmonization and integration opportunities.

Stakeholders and supporting organizational structure

Stakeholders include:

• Users of deliverables
• WAI Education and Outreach Working Group
• ARIA Working Group
• ARIA Authoring Practices Task Force
• ARIA and Assistive Technologies Community Group
• WebApps Working Group

Execution of phases 3 and later call for organizational structure, such as a joint task force or community group or both, that doesn’t exist today.