(Feedback welcome at wai-eo-editors@w3.org or as issues in this repository)

1. Purpose
2. Background
3. Objectives
4. Audience
5. Scope

WAI produces Supporting Documents (listed in Scope below) that are meant to help web developers and content producers effectively implement accessibility standards. The project proposes to redesign how these are presented in order to make supporting materials easier to discover, navigate, and apply to web projects.

W3C/WAI has a wealth of guidance on how to make the web accessible by applying our standards. But we could improve how it is exposed:

• findability: content is in different places, like Techniques in /WAI/WCAG21/Techniques, Tutorials in /WAI/Tutorials, one has to know that and where they exist. One system that links out to these places could mitigate this.
• clarity and consistency: various pieces of guidance have different lay-outs. Ideally it should be more obvious that they are part of one mission: make the web accessible (and guide people who want/have to do that). A shared header and stylesheet (at least: typography, colors and grid) can help with that.
• indication of accuracy: WAI website includes guidance, some old guidance, and a lot in between. Indicating accuracy or age of content should help.
• indication production readiness: we have some technical guidance that explains how to use a technology, but leaves browser support / known browser bugs out of scope (see aria-practices/issue-353#comment-368091861, also the aria-at project). Developers may implement patterns that won't work well (now). Not our fault, clearer labeling and compatibility info could avoid potential inaccessibility (maybe complemented with “Tell AT vendor about this bug” button)
• indication of requiredness: we want to make sure it is clear in how much our documents are required or the required way to do something.
  • A lot of our guidance is a way to approach a problem, not the only way, that should be clear from the document (see https://github.com/w3c/wai-wcag-supporting-documents-redesign/issues/4).
  • Individual Techniques and Understanding pages are informative/non-normative, this should be clear from the document.

• make guidance easy to discover (via the WAI site, QuickRef, search engines and third party sites)
• make guidance easy to understand and apply guidance (once found)
• make it easier to understand how a piece of guidance fits in the larger ecosystem of guidance
• include more effective ways for users to be confident that specific guidance is:
  • timely and relevant in current technology environments
  • well-supported by assistive technologies

W3C/WAI's Supporting Documents are for two major groups:

• Primary: People who want the web products they work on to conform to W3C/WAI's accessibility standards (including designers, developers, content creators, quality assurance testers). Could be accessibility champions, could be team members looking for minimum conformance.
• Secondary: Educators and auditors

• A designer or developer who is building a new feature, wants to learn valid ways to build their feature conform to WCAG (or UAAG, ATAG, WAI-ARIA)
• A Quality Assurance engineer who needs to approve the implementation of a new feature and wants to find a definitive source and intent
• A content strategist wants to assess whether the content in a new feature has accessibility implications
• An accessibility auditor wants to verify if something was built conform the standard

See also the more comprehensive current user flows.

The following is the level of priority for the redesign of the support documents:

• Understanding
• Techniques (including "Sufficient", "Advisory", and "Failure")

Apply the redesign, improve the user interface, improve findability, and make recommendations on how to visually treat outdated guidance.

To make our accessibility information easier to find, we could expose most or all of it via one portal that is designed with user needs in mind.

• Understanding
• Techniques (including "Sufficient", "Advisory", and "Failure")

• ACT Rules
• COGA design guide - see the requirements
• Low vision supplemental guidance
• Mobile supplemental guidance

• ARIA Authoring Practices

• WAI Tutorials (including AV Media)
• Getting Started Tips
• Easy Checks

Explicitly not included in scope of this project:

• improving the content of actual guidance