APG Redesign Wireframes

[isaacdurazo]

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

[jscholes]

@isaacdurazo Thanks for providing such descriptive textual wireframes! This is positive stuff.

There are two elements in the header:

1. A "Skip to Content" link should probably be added as the first element in the header, given that there will now be multiple pages to browse and therefore repeated header content to bypass on each one.
2. This is more of a semantic mark-up/hierarchy thing, but the navigation should be a child of the <header> element even though they are phrased as siblings in the textual wireframes.

There are four main navigation items:

Should the home page be included in the nav? Users may appreciate it, if there are W3C and WAI logos between the APG logo link and start of the nav.

Home Page

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

The current version will soon be 1.2. Although I thought I'd heard @mcking65 mention at one point that the APG wouldn't be explicitly versioned in future?

Design Patterns and Widgets Page

An Icon that represents the pattern.

Keep in mind that the icon image should follow the title heading in the DOM on each card, particularly if alt text is provided for the images. They sound decorative to me, though.

Design Pattern Examples Page

This page contains examples grouped by role and by properties and states.

This raises similar questions to those highlighted by the ARIA AT reports flow. I kind of understand why someone would want to locate examples by role, but I'm not sure why they would want to filter by properties and states. E.g. I would think a web developer was approaching a problem from a suboptimal angle if they were trying to determine the correct design pattern to use based on the fact that it should use aria-expanded.

On the other hand, I can see cases like somebody not being quite sure how to use e.g. aria-valuenow and aria-valuetext, or the differences between them, and in those cases maybe this would be helpful? However, it has to be balanced with the aim to encourage workflows which will result in the most accessible outcomes. For instance, would we want to encourage a web developer to click on examples by putting it in the main nav, when design patterns is what they really would have benefited from more? And vice versa.

Single Design Pattern Example Page

It's not clear to me from the textual wireframes whether the example pages will include the header and footer from the rest of the site?

[isaacdurazo]

Thanks so much for the comments @jscholes I agree with your suggestions. Here are the answers to your questions:

Should the home page be included in the nav? Users may appreciate it, if there are W3C and WAI logos between the APG logo link and start of the nav.

I think this makes sense and I don't see why not have it.

The current version will soon be 1.2. Although I thought I'd heard @mcking65 mention at one point that the APG wouldn't be explicitly versioned in future?

You are right! I tried not to make changes to the existing copy. The idea is that Info related to versions would be available in the About.

Keep in mind that the icon image should follow the title heading in the DOM on each card, particularly if alt text is provided for the images. They sound decorative to me, though.

Yeah, I think it would be repetitive to have alt text for these images because they are decorative.

Lastly, with regard to the Examples Page, I see your point. Again, I tried to leave the content as-is for now and focus on re-organizing things first. We need to spend more time figuring out what the best approach is to turn this into a more usable page, by either adding some sort of filter mechanism or something similar.

It's not clear to me from the textual wireframes whether the example pages will include the header and footer from the rest of the site?

Yes, all pages will share the same Header, Nav and Footer.

Thanks again, James!

[jongund]

@isaacdurazo

I think the primary navigation should have the following menu items:

• Getting Started
• Widgets
• Landmarks
• Labeling/Describing
• Properties/States
• Live Regions
• Touch
• High Contrast

The examples should provide information:

• ARIA version compatibility
• Touch support
• High contrast support
• Last updated

Since this is a living website does it have to be versioned link the a W3C note?

[jongund]

@isaacdurazo
The "Jump To" or "Skip To" button should be visible on all pages to support SC 2.4.1 Bypass Blocks requirement of WCAG.

[jscholes]

@jongund Personally, I find the navigation in the wireframes pretty easy to understand; many of the topics you outlined like labelling, live regions and touch support can live in the fundamentals section with a more descriptive name for that section if required. Adding them all upfront to the navigation is, IMHO, too much cognitive overhead.

[isaacdurazo]

@jongund could you explain a little bit more about your suggestions and what is it about the wireframes you think we are not accomplishing?

I also want to remind you that for this initial step of the redesign process, we should focus on the content we currently have. I know there's a lot of content we want to include in APG, but trying to do so at this early stage of the redesign would complicate things greatly.

[jongund]

@isaacdurazo

Widget and Landmark roles are two very different things and I think it is better to have them in separate sections. There are other types of roles (e.g. document), but we do not have any guidance or examples for them, and so I have not included them in the menu.

An important part of the practices is the support we have added for touch and high contrast and we need to have sections that talk about these issues, since it is something important for developers to understand. We have a lot of examples that have not been updated to support them, so if we don't have a specific section the concepts the will be thought of in the examples as an optional feature, since they are not directly related to the use of ARIA.

Live regions are also misunderstood and differ from landmark and widget roles since they can be defined with either roles or properties, we need to make this easy to find, rather than buried in with other roles and properties.

The new website should help people think about what they need to consider at a high level for accessibility, so updating the primary menu will help orient users to the higher level concepts they need to consider and maybe help the APG focus its attention on filling in potential gaps in guidance.

We have guidance for many of the properties and states.

I think we have content for much of these menu items, and if we don't we can prioritize them in the APG work.

Labeling is also an important issue due to the complexity of the algorithm for aria-labelledby and aria-describedby. The APG need to provide a simple approach to the use of aira-labelledby by documenting what actually works across browsers. Aaron Leventhal said it is very unlikely there will be any changes to the code in browsers for labeling, due to it not being touched for a long time and the complexity of making changes to it. The APG should provide guidance on the most reliable use cases and encourage developers not to use complicated markup to label items.

[a11ydoer]

@isaacdurazo

Here are both my feedback and group's feedback from the meeting on August 10, 2021.

1. The prototype is visually very appealing, particularily "Pattern and Widget" section
2. Consistent sub-navigation can be helpful so that users can avoid constant scrolling or only depend on "back to top" button
3. Improving navigation labeling -"Index" instead of "Examples"
4. Moving "Landmark region" under "Fundamentals" be more visible - potential solution or stop gap measure can be also adding "landmark" under "Patterns" menu?
5. Adding search input box under "Patterns" page so that patter name can be searched without scrolling
6. Adding Direct access to Widget example(Call to action button) under each pattern page
7. Adding Breadcrumb or link to show releationship among examples and pattern
8. Moving ARIA Rule(originally in "readme" section) from "Home" to "Fundementals"
9. Adding "browser and mobile support" in "Home" page to separate note
10. Reconstructing "Home" page content with audience focused content writing (future work item)
11. Fixing the broken link to each pattern example
12. Important but out of scope comment regarding requested feedback on August 6, 2021

• W3C WAI template issue
• No implementation for "jumpto"
• Skipped heading level
• Some color contrast violation

[richnoah]

After analyzing the feedback and prioritizing items that will support the upcoming usability testing the following items are deemed in scope:

• Implement "Jump To" functionality
• Correct skipped heading levels
• Update Pattern Card link area - only heading will be clickable
• Design and add side navigation to subpages of Fundamentals
• Fix broken link to each pattern example
• Correct color contrast issues
• Correct issues due to CSS modifications
• Correct H1 in Examples

[richnoah]

The above items have all been resolved and usability testing is proceeding.