APG’s goal is to be a trusted reference for Web developers, Accessibility specialists, Assistive Technology Developers, Browser Developers, Interaction Designers, and anyone who has some experience in Accessibility and wants to know how to implement an experience in an accessible way. This project’s redesign intent is to make APG more visible for the accessibility community and make its resources easier to find, navigate and use.

APG is currently a standalone document that follows the W3C’s Technical Report format and is accessible through /WAI/standards-guidelines/ under the Technical Specifications section. We want to make APG more visible by integrating it better into WAI and have a direct link from /WAI/Design & Develop

The content’s format is a single-page document. It is overwhelming and easy to get lost. We want to make APG more usable by splitting up the content strategically and come up with a new information architecture.

To find content one has to navigate the site, scrolling or using the table of contents on the side. We want to incorporate a central navigation that provides easier access to the content and areas of most interest and make things easier to find.

Mobile support is not fully optimized and is difficult to use APG on a mobile device. We want to make APG responsive as part of this redesign so people have a good experience on a tablet or a phone.

People with some knowledge of Accessibility who work in design and engineering and want to make sure the experiences and components they are implementing meet the accessibility standards. This includes accessibility specialists, assistive technology developers, testers, browser developers, web developers, interaction designers.

A web developer who wants to implement a new widget and wants to learn if there is something similar in APG. A tester who needs to make sure a newly implemented feature meets the accessibility standards before it is deployed to production. An accessibility specialist who wants to advise a client on what component to use and how to implement it in an accessible way. An Interaction Designer who wants to understand what keyboard interactions to expect from a widget