Followup discussion for summary table format

[s3ththompson]

Forking the discussion from the review of "Add a new simple reports," #233

cc @rmeritz @jscholes

From @jscholes on Dec 10, 2020, 1:03 PM EST

It was my understanding that in the initial designs, the highest level columns would only show the aggregate percentage of passing required tests across all AT/browser combinations, and that users would need to dig down to determine data for a specific combination. But in this implementation, the summary table has columns for JAWS/Firefox and VoiceOver/Safari.

The screen reader speech is already quite verbose because of the wording of the column headers. For example, "JAWS with Firefox Required Tests Passing" is 11 syllables before users hear the data. If NVDA is the AT under test, that immediately adds an additional three syllables even though the length of the text is the same.

This is also problematic for braille users. The JAWS/Firefox example would just about fit a 40-cell display if users opt for contracted output. But:

that doesn't guarantee that the data will be available without scrolling/panning; in uncontracted braille, users will likely need to scroll/pan to even read the header; the screen reader will add its own information to the output (such as cell coordinates); and many people use braille displays with less than 40 cells. Much of the frustration for braille users will likely also be experienced by those relying on screen magnification. This is quite difficult to read with two combinations. The more that are added, the more cognitive overhead will be imposed.

Appreciate any thoughts here. The mark-up is semantically accessible, e.g. the column headers are correctly associated with the cells underneath. It's just impossible to scan quickly.

From @jscholes on Dec 11, 2020, 3:45 PM EST

For now, I shortened the label for the AT/Browser Pairs to be "AT/Browser Passing Tests". Is this enough to address your problem?

This only changes the problem statement, because now the text is still quite long without indicating that only required assertions are considered in the percentage.

Replace the existing summary table with two new ones.

I think you've already highlighted the problems with this approach. It feels confusing and would require a new page layout for when users click on a specific combination.

An approach I'm thinking through right now would be to change the table to only have two columns: example in the first, and "Required Passing Assertions" in the second. Then, for each cell in the second column, include a list like:

• JAWS/Chrome: 100%
• JAWS/Firefox: 90%
• ... etc.

The issue with this is that it doesn't allow easy comparisons between a single AT/browser combination across rows. For example, if I wanted to determine the support for two checkbox patterns with macOS VoiceOver and Safari, and they were at the bottom of these new lists, I would have to find the last item in the list each time. Appreciate any thoughts here, although note that the list could be horizontal or vertical.

One thing about the current header for the first row. It reads, "Design Pattern Examples", but:

• Should it be "examples", plural? Other than the first one, each row only relates to a single pattern, and the text "All Design Pattern Examples" in the first row is pretty clear.
• Should we be using the word "example" at all? On the test queue, project wiki, etc., these are always described as "test plans".

[jscholes]

After discussion with @sinabahram, we think the information about what the data represents (passing required assertions) should be moved into the heading before the table, with the table aria-labelledby that heading. The column headers can then just be the names of combinations like JAWS/Firefox.

If any additional info is needed that won't fit in the heading (or would make the heading too long), it can follow the pattern using aria-describedby written about in #233, with a paragraph between the table and heading. Let us know any thoughts and/or questions.

[s3ththompson]

@jscholes I was planning to send a followup reply with some more ideas about pushing forward but you beat me to it!

I think this sounds like a good solution. I was going to reframe the discussion around what seemed to be the underlying issue, which was coming up with a pattern for how to handle tables with headings that are long or complex.

It sounds like a combination of aria-labelledby and aria-describedby will go a long way.