Over the course of two weeks, we talked to stakeholders of the Aria Authoring Practices Task Force and users of the Aria Authoring Practices Guide, also known as APG, to collect their insights and define the best approach for transforming APG from a webpage into a website and improve the user experience.

Talking to stakeholders helped us establish the foundations for the design process of the project, understand the goals of APG, how we intend this redesign to help people using APG, what usability problems this resource is currently facing, what constraints we might face along the way and what success would look like.

We also talked to nine people in the accessibility community that included managers and directors of accessibility IT departments, accessibility engineers, web developers, and IT Accessibility student assistants to learn about how they currently use APG, what their motivations are and what pain points they have experienced while using it.

One of the main goals of APG is to be a trusted reference for Web developers, Accessibility specialists who support designers, engineers, and testers, Assistive Technology Developers, Browser Developers, Interaction Designers, and anyone who has some experience in Accessibility and want to know how to implement an experience in an accessible way.

While the project doesn’t target people who are just getting started in the field, it should point them to other basic getting started resources.

People use APG to make sure their widgets meet the standards. They use it as a reference when implementing something as simple as one single component or as part of larger projects like website redesigns or when testing components and advising clients. Being a resource backed by W3C makes APG seen as trustworthy. Like the “source of truth” in a way.

Participants described (almost unanimously) mostly using Design Patterns and Widgets, which is considered a point reference when they are implementing widgets and want to make sure these are accessible. Secondly, the Example pages, which people tend to like considerably because as described by many, they are easy to share and consume.

Another three sections mentioned a couple of times were “Read Me First”, "Providing Accessible Names and Descriptions” and “Landmark Regions”, although these were considered by people as something more fundamental.

Sections like “Developing Keyboard Interface” and “Intentionally Hiding Semantics with presentation role” were considered too specific and no one really was able to share a case when they had used them.

Quite a few participants appreciated having the “No ARIA is better than Bad ARIA” section at the beginning and even suggested that more prominence would be better.

There were also several positive comments about pieces of content like Keyboard Interaction, Keyboard Support, and the Role, Property, State, and Tabindex Attributes table. People especially like the simplicity of these components.

Everyone shared the same sentiment about the document being too long and overwhelming, sometimes even too verbose which confirms our assumption about the usability problems of a single-page website.

People said it was hard to find things and easy to get lost when scrolling through.

Some also mentioned things about certain missing topics, like mobile design patterns, touch screen support, etc, but since that was out of scope we didn’t elaborate much on that.

Another aspect shared by a few participants about the experience of using APG was about some examples and design patterns not being representative of real-world cases, which prompted some conversation about their interest in participating with ideas or feedback but not finding an easy way to engage with the community group.

Participants were eager to share their ideas for how to make APG better. Some of them are already discussed as part of our assumptions, which in a way validates them, but let’s not consider these final solutions since this research was a qualitative analysis. Here is the list of ideas:

• A central navigation
• To have the content broken up, especially for Design Patterns and Widgets
• A sorting, filter, and/or search mechanism
• A way to jump right into the example pages.
• More simplicity in the content.
• An indicator that tells the user when there something new published or when something has changed
• A responsive website
• A collapsible and expandable feature for certain areas
• Ability to embed APG content elsewhere
• Flexibility to still keep a one-page view of the document
• An easier way to provide comments, feedback, or participate in APG.

Improving the user experience first should be considered the biggest priority right now. We can approach this by designing a new Information Architecture for the site. That would allow us to more easily move to the next step, which is to start adding features and extra functionality to the website, such as filter and/or search mechanisms, embeddable examples, etc.

Lastly, once we are able to provide a better experience for people, we will be able to more easily fill the gaps in the content by having a redesigned website first.

We think that by making APG a more usable and visible resource for people implementing accessibility components we will increase its usage by Designers and Developers in the Accessibility field.