Define content for About section that explains how to interpret and use the AT support tables

[ccanash]

As part of the improvement to the APG support tables we will include a link to explain the data displayed in the table.

This tasks is to define:

• The location of the link
• The text to be displayed for the link
• The text that will a explain the data displayed on the table.

Some ideas shared by @mcking65 :

• include a link above or below the table to “What does this data mean?” or “How to interpret this data”
• link should be outside of the iframe, i.e., not part of the content returned by the aria-at query. The link could be to a page in the APG about the specific data surfaced in APG and written to address the APG audience with its specific aims. That page could an APG page

[boazsender]

I've written a draft proposal for this language @mcking65: https://docs.google.com/document/d/1QwFgvDYBGGBgMmJCDUUcLdXBWerEmXpKAwFv1_QkMFY/edit

[mcking65]

@boazsender

The doc seems to be describing the current support table because it says only the values for "MUST" are shown and it says:

Screen readers are on the y axis (vertical) and browsers are on the x axis (horizontal).

In the new table, we have columns for "MUST" and "SHOULD" as well as columns for browser and AT. This new page needs to describe the new table we are about to launch.

The doc seems to be written with the goal of describing the table vs helping readers understand what the data mean and how to interpret it. Some of the APG readers who have provided feedback on the current tables expressed that the meaning of the data is not clear to them so they do not know how they could make use of it.

We cannot assume APG readers know anything about the ARIA-AT community group or its goals. However, this page should not explain either the group or its goals; it can link to aria-at where appropriate. The explanation of the approved or unapproved status should thus be appropriately broad. Also keep in mind the long term goal of a scope larger than screen readers.

WRT specific utility, it is important for readers to have some understanding of how aria-at uses must/should/may (defined in the aria-at wiki glossary). In practice:

• If an example has less than 100% support for MUST assertions, readers should understand the support gaps before implementing the pattern in a production environment. This page could summarize some options/considerations for those situations.
• If testing their own implementation of an example with a screen reader that has less than 100% support for both MUST and SHOULD, they should be careful not to modify their code to accommodate the screen reader failure, especially if that would affect screen readers that do not have that support failure.

[mcking65]

@boazsender

I created a stub page in the about section; you could add content in the draft PR #3000 instead of the google doc.

[boazsender]

@mcking65 I pushed a new commit on PR #300 with an updated draft. You can read it from the deploy preview.

I'm hoping to work on this a bit more this week and add further guidance, but wanted to push something up and get a gut check. Let me know what you think.