I would like to have the "Skip To Content" link always visible, for example centered at the top of the page.

This would make the typically "hidden" accessibility information of headings and landmarks visible to all users.

The benefits of this approach are:

• It increases the awareness to everyone the existence of headers and landmarks on a web page and they can be used for page navigation by all users.
• Authors will have an incentive to be more careful in defining landmarks and headings if they know that everyone will be able to see and use them.

As part of the September 14, 2021 APG Task Force Meeting a request was made to investigate a build process for deploying to both production and staging from separate branches in the github repository.

During the analysis phase of providing an answer to this request the following questions have been raised:

1. What will be the final production url for the redesigned website?
2. What repository will be used? https://github.com/w3c/aria-practices
3. What branches will be used for the build process (production & staging)

Text-based and Visual High Fidelity Mockup

Text-based Mockup

Hero Section

The hero section of the home pages is comprised of a dark blue box aligned to the left that takes 75% of the width of the main container; it has a welcoming text in white that includes an h2 that reads "Get empowered to create accessible rich internet applications" and the font size for this text is 16px. Underneath there is a p that reads "Learn how to use ARIA to create an accessible Rich Internet Application. The ARIA Authoring Practices project provides guidance on the appropriate application of ARIA, describes recommended usage patterns, and explains concepts behind them"; the font size for this text is 16px.

On the right-hand side of the hero section, there will be an illustration representing APG; this will take the remaining space in the section.

Subtle ornamental and minimalistic geometric elements float around in the hero section.

Main Content

The main content area has three sections that cover APG'a most common resources, current work and how to collaborate with the Task Force and the project.

Every section in the main content area has a consistent style and type of content for its header, which contains an h3 and a p centered on the page; the h3 has two lines of text with different styles each; the text above categorizes the section and is either one or two words; it is in gray color, uppercase, and the font size is 16px. The text below is in "W3C blue" and the font size is 38px; it is a couple of lines of text and uses an inviting message. The p contains a brief two-line description of the section in black text and the font size is 16px.

Our Resources

Header

The h3 in this header reads "Our resources" on the first line and "Everything you need to make de Web Accessible" on the second line. The p reads "Recommended approaches to make widgets, navigation, and behaviors accessible using WAI-ARIA roles, states, and properties."

Main Content

The main content of this section includes 4 resources that are structured by an h4 that includes the name of the resource in W3C blue, a p in black that briefly describes it, an a styled like a button in dark blue that reads "Learn more". Next to this block of text, there is an illustration on the side that represents the resource.

The text and illustration of each of the resources in this section alternate visually, meaning that the first one has the text on the left and the illustration on the right, the next one does the opposite, so on and so forth.

The resources in the section and their descriptions are:

• h4 Design Patterns and widgets

  • p Learn how to make common rich internet application patterns and widgets accessible by applying WAI-ARIA roles, states, and properties and implementing keyboard support.

• h4 Use of ARIA landmarks

  • p Learn how HTML sectioning elements and ARIA landmark roles are used to make it easy for assistive technology users to understand the meaning of the layout of a page.

• h4 Providing Accessible Names and Descriptions

  • p Providing elements with accessible names, and where appropriate, accessible descriptions is one of the most important responsibilities authors have when developing accessible web experiences.

• h4 And so much more…

  • p Learn about other fundamental accessibility resources and understand how to Provide Accessible Names and Descriptions, implement accessible Grid and Table properties, use Hiding Semantics, and more.

Note: The last resource on this page takes the user to the "Fundamentals" page

Current Work

Header

The h3 in this header reads "Current work" on the first line and "Check out our most recent work" on the second line. The p reads "Review the overall scope of work planned for the APG and supporting deliverables and the timelines for completing our work."

Main Content

The main content of this section includes four resources styled like cards side by side in one row; these cards are white on a light blue background and are structured by an h4 that includes the title of the resource in "W3C blue", a p that briefly describes it, an a that reads "Learn more" in W3C blue.

The resources in the section and their descriptions are:

• h4 Release Plans

  • p Take a look at the plan overview for WAI-ARIA Authoring Practices, priorities, and work in progress.

• h4 Patterns Progress Status

  • p Status of work on design patterns and reference implementations of those patterns for the first release of the ARIA 1.1 Authoring Practices.

• h4 How to write Regression Tests

  • p Learn what the APG Regression Tests test, how to run them, and understand the results.

• h4 Meetings

  • p The APG Task Force meets on Tuesdays from 14:00 until 15:00 Boston time.

Collaboration

Header

The h3 in this header reads "Collaboration" on the first line and "Get involved with our community and our work" on the second line. The p reads "The APG Task Force conducts its work using a variety of synchronous and asynchronous tools. And there are several ways to get involved."

Main Content

The main content of this section includes two resources side by side. They are structured by an icon on top followed by an h4 for the title, a p that briefly describes the resource, and an a in W3C blue.

The resources in the section and their descriptions are:

• h4 Join our community

  • p To join the APG Task Force, individuals must be participants of the ARIA WG. Participants are expected to actively contribute to the work of the Task Force.
  • a Connect With Us

• h4 Contribute to our project

  • p To contribute without joining the task force, see the ARIA Working Group contribute page for general instructions. To contribute to documents under development, see how to contribute to the source repository directly.
  • a Get Involved

Aditional content

At the bottom of the "Collaboration" section, there is a dark blue box with white text that takes 75% of the page and is horizontally centered; it contains information about APG's mailing lists. This component is structured by an icon on the left and an h4 for the title and a p to provide a description; both aligned to the right.

This boxes text reads:

• h4 Mailing Lists
  • p The APG Task Force uses the [email protected] mailing list (mailing list archives) for email discussion. Participants are automatically added to the mailing list when they become a participant of the Task Force.
    Discussions of the task force prior to September 2017 are archived on the public-aria mailing list.

Visual High Fidelity Mockup

Usability Study Plan

Prototype: http://wai-aria-practices.s3-website-us-east-1.amazonaws.com/

Objectives

1. Determine design inconsistencies and usability problems.
2. Test the effectiveness of the new information architecture.
3. Identify if users can easily find and use specific resources.

Research Questions

1. Are participants able to navigate through the website with the new information architecture?
2. How easily can users find the resource they are looking for with the new central navigation?
3. What issues do participants have when trying to find a particular resource?
4. What is the most likely approach a participant takes when trying to access a pattern example?
5. How discoverable are specific sections on the Fundamentals page?

Logistics

Each session will take 1 hour and will be conducted remotely via Zoom or Google meet depending on the participants’ preference. Sessions will be scheduled for the week of Sept 13, 2021, and participants will be compensated with a $100 Visa gift card for their time.

Participants Profiles

The participants in this study are people with different levels of experience in Accessibility, from a couple of years to more than 12 years in the field. Some spend a few hours a week and others work full time implementing accessible experiences.
The job roles of participants include web accessibility expert/consultant/lead, engineer/developer, designer, UI/UX Engineer, and QA Tester.

Scenarios, Tasks, and Questions

1. You are just starting to build ARIA widgets. Find the resources to understand how to implement keyboard support for them.

   • Task completion: participant finds fundamentals/keyboard-interface/

2. You are looking to implement a tri-state checkbox pattern as part of a design system. Find the best practices to implement that pattern.

   • Task completion: participant finds /patterns/checkbox/ and then /examples/checkbox/checkbox-2/checkbox-2.html

3. You are having issues with NVDA/JAWS announcing an ARIA 1.1 Combobox role properly. Find the Combobox example so you can test it.

   • Task completion: participant finds: /examples/combobox/combobox-select-only.html

4. One of your colleagues has a question about a navigation pattern on your company's website.

   This current pattern uses an unordered list in a nav; if a top-level link has a sub-menu of child links, the top-level link uses aria-expanded and the sub-menu uses aria-hidden for toggling the sub-menu.

   His question is, should this pattern use aria-haspopup in addition to aria-expanded and aria-hidden?

   Look up the documentation about this type of pattern.

   • Task completion: participant finds /patterns/menubutton/ and then /examples/menu-button/menu-button-links.html

5. One of your colleagues is just starting with Accessibility and you would like to point them to the different landmark roles and their examples.

   Look up the documentation about landmark roles.

   • Task completion: participant finds /fundamentals/landmark-regions/#landmark-roles

Post Test Interview Questions

1. How would you describe your overall experience?
2. What, if anything, surprised you about the experience?
3. What, if anything, caused you frustration?
4. What do you think about the website overall?
5. What do you think about how information and features are laid out?
6. What do you wish this website had that it currently lacks?

The following is a list of issues discovered with the EOWG Template while developing the ARIA APG Prototype.

• The logo/title on the top left should be a link to the root of the document.
• Lack of W3 favicon
• Nav shouldn’t have aria-label="Context for this document"
• H1 shouldn’t be wrapped in a banner (). Make sure headings are not wrapped in banners
• While tabbing headings are not announcing the name
• It is not clear the footer is a footer. The landmark wasn’t announced by the screen reader.
• Current items in the main nav don’t have the yellow bar underneath them

Text Based and Visual Wireframes

Text-based Wireframes

These wireframes proposals take into consideration the usage of the new template the EOWG has been working on. The new Information Architecture consists of five main pages and two subpages:

• Main Pages
  • Home Page
  • Design Patterns and Widgets
  • Examples
  • Fundamentals
  • About
• Subpages
  • Single Design Pattern Page
  • Single Example Page

Shared elements between pages

There are three components shared across all pages: header, navigation, and footer. They have the following contents:

Header

There are two elements in the header:

• ARIA Authoring Practices (aligned to the left)
  • This element represents, in a way, what would be the ARIA Authoring Practices (APG) logo.
  • Clicking this element will take the user to the home page, if not already there.
• W3C and WAI logos (aligned to the right)
  • Clicking the W3C logo will take the user to https://www.w3.org/
  • Clicking the WAI logo will take the user to https://www.w3.org/WAI/

Navigation

There are four main navigation items:

• Patterns and Widgets
• Examples
• Fundamentals
• About

Footer

The EOWG template, which is what we will use for APG, reuses the same design, content, and structure the WAI website uses for its footer. There are three components as part of the footer:

• Help improve this page
• Information about the authors and when the page was published
• WAI site links, social links, copyright, etc

Home Page

The home page is where the user lands when loading the website for the first time. It is also accessible by clicking the APG logo in the Header if the user is on a different page.

This page contains introductory information about the project. These are the details:

Main Content

The heading level 1 (h1) of the page is "WAI-ARIA Authoring Practices 1.1".

Following the heading level 1, we have five sections. Each section has a heading level 2 (h2) that reads:

• Abstract
• Introduction
• No ARIA is better than Bad Aria
• Browser and Assistive Technology Support
• Mobile and Touch Support

Design Patterns and Widgets Page

The Design Patterns and Widgets page lists all patterns available. It is accessible from the main navigation by clicking “Design Patterns and Widgets”. This proposal introduces a three-column grid-layout where each Design Pattern (or widget) looks like a card.

Having a grid layout instead of a list of patterns could help the user identify something they are looking for easier and using a card allows us to include a little more information besides only the pattern name. These are the details:

Main Content

The heading level 1 (h1) of the page is "Design Patterns and Widgets"

Design Pattern Card

This card represents a single pattern and contains the following information:

• An Icon that represents the pattern.
  • Note: This could be a great way to visually represent each pattern and could make it easier to parse for sighted users when scrolling through the page. It will definitely be challenging to maintain but worth considering as an option.
• The pattern name as a heading level 2 (h2).
• A description excerpt of the pattern. Perhaps two or three lines of text.

Single Design Pattern Page

The Single Design Pattern Page is accessible from the Design Patterns and Widgets page when clicking one of the patterns.
This page contains all the information about a single pattern. These are the details:

Main Content

The heading level 1 (h1) of the page is whatever the design pattern name is and is followed by an introductory paragraph about the pattern.

Following the heading level 1, we have the same three sections we have in the current content structure we have in APG. Each section has a heading level 2 (h2) that reads:

• Examples
• Keyboard Interaction
• WAI-ARIA Roles, States, and Properties

Design Pattern Examples Page

The Design Pattern Examples Page is accessible from the main navigation by clicking “Examples”.

This page contains examples grouped by role and by properties and states. In this proposal, we have a table of content on the left and the main content on the right.

Main Content

The heading level 1 (h1) of the page is "Design Pattern Examples".

Following the heading level 1, we have the same two tables we currently have in APG. Each table has a heading level 2 (h2) that reads:

• Examples by Role
• Examples by Properties and States

Table of Content

This component is on the left-hand side and has a heading level 2 (h2) that reads: Table of Contents. The idea is that this component will “stick” to the top as the user scrolls through the page.
It is followed by a list of two links that match the sections of the page

Single Design Pattern Example Page

The Single Design Pattern Example Page is accessible from the Design Pattern Examples page and the Single Design Pattern.

This page contains all the information we currently have in an example page in APG organized into two areas:

Main Content

The heading level 1 (h1) of the page is: Whatever the design pattern name is plus the word “example”.

Following the heading level 1, we have the same four sections we have in the current content structure we have in APG. Each section has a heading level 2 (h2) that reads:

• Example
• Accessibility Features
• Keyboard Support
• Role, Property, State, and Tabindex Attributes
• Javascript and CSS Source Code
• HTML Source Code

Help Links

This component is aligned to the right and contains the following links:

• Design Pattern
• Report Issue
• Related Issues

Fundamentals Page

The Fundamentals Page is accessible from the main navigation by clicking “Fundamentals”.

This page contains information considered foundational. In this proposal, we have a table of content on the left and the main content on the right.

Main Content

The heading level 1 (h1) of the page is "Fundamentals".

Following the heading level 1, we have six sections. Each section has a heading level 2 (h2) that reads:

• Landmark Regions
• Providing Accessible Names and Descriptions
• Developing a Keyboard Interface
• Grid and Table Properties
• Intentionally Hiding Semantics with the presentation Role
• Roles That Automatically Hide Semantics by Making Their Descendants Presentational

Table of Content

This component is on the left-hand side and has a heading level 2 (h2) that reads: Table of Contents. As previously stated, the idea is that this component will “stick” to the top as the user scrolls through the page.

It is followed by a list of six links that match the sections of the page.

About Page

The About Page is accessible from the main navigation by clicking “About”.

This page contains information about the project that is considered secondary in comparison to what we have on the home page. These are the details:

Main Content

The heading level 1 (h1) of the page is: About ARIA Authoring Practices and is followed by this introductory information:

• This Version
• Latest published version
• Latest editor's draft
• Previous version
• Editors
• Former editors

Following the heading level 1 and the introductory information we have four sections. Each section has a heading level 2 (h2) that reads:

• Status of This Document
• Change History
• Acknowledgements
• References

Visual Wireframes

Home Page

Design Patterns and Widgets Page

Single Design Pattern Page

Design Pattern Examples Page

Single Design Pattern Example Page

Fundamentals Page

About Page

The page table of content is in the wrong place in the DOM. It is currently inside the main element after the H1, and it is inside of a complementary region.

the TOC links need to b:

• In a nav instead of complementary
• The nav element needs accessible name of "Page Contents"
• the nav element should immediately precede the main element in the DOM.
• the H1 should be the first element inside the main element

Introduction

Over the week of September 13 of 2021, we conducted the first Usability Study for the Aria Authoring Practices Guideline (APG) website redesign project. The goal of this study was to determine the effectiveness of the new information architecture of the site in reducing the time and effort it takes users to find the resources they need as well as identify design inconsistencies and usability problems.

The majority of the participants of the study were successful at completing their tasks in a reasonable amount of time. It was clear that having a central navigation and the content split up sped up the process of finding resources. In addition, we identified several areas of improvement where we can simplify and continue improving the experience for users.

Participants

We recruited participants via https://web-a11y.slack.com and Twitter. Their profiles included people with the following roles: Accessibility Specialist, Front End Developer, Designer, UI/UX Engineer, QA Engineer, and Accessibility Tester. All of them with at least 2 years of experience in Accessibility and the majority with more than 6 years in the field. All but one participant were somewhat proficient at using a screen-reader and two of them declared to be very proficient.

Tasks and Scenarios

We designed tasks and scenarios for the study to cover and test different areas of the site. Participants were able to navigate through different resources on the Fundamentals page, explore different design patterns and dive into some of their examples.

For more details about the tasks and scenarios, please refer to the APG Redesign Usability Study Plan.

What went well

For the most part, participants were able to complete their tasks without much difficulty.

• People with the most experience in Accessibility and those who use APG often, found resources quickly, while those with less experience and familiarity with APG required a little bit more time.
• The new central navigation sped things up when finding resources and it received several positive comments.
• People unanimously agreed that the current content categories made sense.
• People liked the cards’ layout of the Patterns and Widgets and Fundamentals pages. Many mentioned how clean and easy it is to look at all these from a high-level view.
• Several people commented they loved the usage of illustrations for each pattern, especially how those would become recognizable after visiting the page often.
• When searching for different resources under specific patterns, such as implementation techniques, keyboard support, best practices, and examples, the majority of participants had no major issues.
• A couple of participants appreciated the usage of a side navigation in pages like “Landmark Regions”, which gives them a clear outline of the content of the page.

Positive comments from participants

Easy and comfortable. Easy to navigate and to find examples. Not mentally heavy.

It’s really nice to have horizontal navigation instead of the old one.

With regard to the Patterns and Widgets page

As someone who goes there very often, I love that I’m gonna start recognizing these icons and don’t even have to read to select what I need.

This is lovely! This is actually super great!

I like that there are other ways to navigate to examples, either through the patterns page or using the Examples page.

I appreciate having a standalone section for Fundamentals. That’s gonna help a lot of people

It is a simple interface and it’s really great to be able to share urls more easily.

Areas of improvement

• When participants were asked to search for Keyboard support, several preferred searching for a pattern example and learn about keyboard support from there rather than looking under Fundamentals.
• When searching for examples, people took different approaches. Some went through the Examples page and the tables we have there, but it was difficult, others went through the Patterns and Widgets page.
• When asked about finding the best practices to implement a specific ARIA Widget, everyone was able to find the Widget, but a couple of participants didn’t notice the links to its examples.
• When asked to find some examples of Landmark roles, people would generally look under fundamentals last. A couple of participants looked under the Examples page without finding any. Only one participant was able to find an example of a landmark role from the Landmark Regions page.
• A couple of participants didn’t notice the cards under fundamentals had a clickable heading.
• When participants were asked to find information about the ARIA attributes of a particular Widget, it generally took them some time. Some went through the single pattern page of said widget or the example of that widget, and others went through the Examples page’s tables.

Feedback from participants

• Almost half of the participants considered we should re-think the order of the navigation elements and have Fundamentals come first. Right after Home.
• The home page is pretty content-heavy and could be re-worked, especially to make it friendlier. Consider adding information about when ARIA came into existence and why it did. It would be nice to promote other types of content as well, like a few relevant patterns.
• In some places, it would be nice to link to WCAG.
• For the Patterns and Widgets, and the Fundamentals pages consider cards to be clickable or have a “read more about x” link.
• Incorporate search functionality
• It would be nice to include a content outline or side navigation on lengthy pages that don’t have it
• Comparisons of how something looks with and without ARIA would be great.
• Add breadcrumbs when possible
• In the single Pattern page, have a tab panel for JS, CSS, and HTML

Next Steps

Now that we have concluded the first usability study and we have identified the successes and areas for improvement, we will

• Think about how we can approach each of the challenges usability test participants faced.
• Create a list of recommendations for each of the usability issues
• Document bugs and accessibility problems found during the study
• Estimate and prioritize the improvements we want to make

This checklist includes UX and accessibility issues, as well as bugs documented before and during the first usability study for the APG redesign project.

UX issues

• In the main Nav, change the word “Examples” to “Index”
• Create a “Landmark Regions” Pattern that links to the Landmark Regions self-contained page.
• Improve Design of single Pattern and single Example pages
  • In the single pattern page, make the link to Examples more prominent
  • There are visual treatments we can add to elements and sections here to improve the look and feel.
• The "ARIA Authoring Practices" logo/title on the top left should be a link to the root of the document.
• Missing favicon!
• Reprioritize Navigation items by moving Fundamentals to be next to Home.
• Add side navigation to
  • single pattern page
  • single example page
  • and Index Page (previously Examples page)
• Redesign Home page
  • Move "No ARIA is better than Bad ARIA" from Home to Fundamentals.
  • Add "browser and mobile support" on the Home page to a separate note. Deprioritize this visually.
• Add “Read more about x” link to cards under Patterns and Fundamentals pages
• Fix styling for Landmark Regions self-contained page.
• Audit content
  • to fix inconsistencies
    • E.g. Sometimes we refer to Patterns as ARIA design patterns, widgets, or simply design patterns.
  • There are also cases where the copy assumes a slightly different structure and presentation style (e.g. saying "This section is informative" no longer makes sense when the content is presented as a website instead of a specification).
  • to remove repetition
    • When looking at a pattern page, we have a “Keyboard Interaction” section with a bulleted list of the specs, the same for “WAI-ARIA Roles, States, and Properties”. When we go to the example plage of the same pattern, we present again the same information but call it “Keyboard Support” and “Role, Property, State, and Tabindex Attributes”, and present the specs in a table instead.
• Implement breadcrumbs were appropriate
• Implement Search Functionality
• Implement Tab panel for JS/CSS and HTML in ex

Accessibility issues

• There are missing regions on the home page
• There is no banner or header region, which might be causing that
• Nav shouldn’t have aria-label="Context for this document" it feels weird
• H1 shouldn’t be wrapped in a banner (). Make sure headings are not wrapped in banners
• While tabbing headings are not announcing the name
  • The Screen reader output is: link heading 2, link heading 3, etc
  • Using arrow keys did announce the headings
  • Note: This might be because headings have an empty anchor tag next to them for some reason.
• Not clear the footer is a footer. The landmark wasn’t announced by the screen reader.
• Implement “Jump to”. Right now is only “skip to main”
• Side nav is behaving weirdly. Screen reader user hears section symbols all over the place
• Heading level 3 is announcing 2 items because we have an anchor tag with a section symbol as well.
• “HTML-ARIA” link has “ARIA in HTML” as its title, which is redundant
• Steps under “General Principles of Landmark Design” should be H4s instead of bold paragraphs
• Avoid orphan characters at the beginning and end of paragraphs when using inline links.
• Screen reader is not announcing when the user selects code in source code.
• Use tabs instead of spaces in code examples.

Bugs

• Navigation Menubar and Tree view example pages have “Mythical University” as the heading.
• Code highlighting is not working.
• Current items in the main nav don’t have the yellow bar underneath them
• “Breadcrumbs” heading wasn’t a link when the user landed on the patterns page. He navigated somewhere else and then back and it worked. This is a bug maybe in the SR, which could be navigated by having a “read more” link