Mockups for Assistive Technology Support table in Patterns Example's pages

[isaacdurazo]

These mockups show how we could display an Assistive Technology Support Table (also known as test reports) from ARIA-AT on an APG Pattern Example page. My intention is to start a discussion to decide what (if not all) of these features we want to implement.

My thinking is we should start simple, but wanted to include as many possibilities as I could come up with so we have an idea of an end goal.

Pattern Example page mockup

Visual Version

Text-based version

A new section with an H2 that reads "Assistive Technology Support" has been added at the end of the page, right after the "HTML Source Code" section. This section has a disclosure component after the heading, indicating the phase in which the test report is. The phase could be Candidate or Recommended. After the disclosure component, we have a table that displays the actual test report from its highest-level view, which has Assistive Technologies with their major version as rows and Browsers as columns.

For the cells where an AT and a browser intersect, we display a progress bar showing the percentage of passing assertions with a text underneath that reads "X% of passing assertions". When we have no test results to display, we show the word "None".

The cells in the test report that display the progress bar, are clickable. Clicking them will take the user to the ARIA-AT website, specifically to the summary report table for that particular AT and Browser combination they have clicked.

Under the Test Report table, there's a primary button called "View Complete Report", which will take the user to ARIA-AT's main report page for the Pattern Example they are looking at in APG, where they can see the Test Reports for all AT and browser combinations

Next to the "View Complete Report" button, there's a secondary one called "Embed". Clicking it will open the "Embed Pattern Test Report " modal. See the next mockup for more details.

Embed Pattern Test Report modal mockup

Visual Version

Text-based version

The "Embed Pattern Test Report modal" has a heading that reads "Embed [pattern name] Test Report" followed by the test report table for the pattern example the user is looking at. Underneath the table, the user has different filters to hide or show data in the table, copy the code and embed the test report somewhere else.

On the left-hand side, the embed filters are split up into two lists:

1. Filter Assistive Technologies. Which is a checklist of all ATs for the user to hide or show.
2. Filter Browsers. Which is a checklist of all Browsers for the user to hide or show.

On the right-hand side, there is a <code> element that contains the code the user can copy to embed the Test Report somewhere else. They can either select the code or click the "Copy Code" located button underneath the <code> contained

[mcking65]

@isaacdurazo Thank you! Excellent start! Covers nearly everything we need.

The embed feature is an awesome stretch goal. That is something we'd like to eventually support for not just this section of the example page, but perhaps several of them.

Two immediate needs we need to address are:

1. Reflecting the status of the test plan with appropriate supporting text
2. Surfacing the major version number of the screen reader.

Also note that we will not show tables without data. I think we should have a different heading and copy if the example does not yet have AT support data. We don't want people to scroll all the way down and then find that there is nothing there.

Here are my suggestions for the above plus some copy adjustments.

Section title

I believe the copy for the H2 should be "Assistive Technology Support". If we are not yet showing data for the example, then the copy for the H2 could be "Assistive Technology Support Data Not Yet Available". If the data is not yet available, we can include a paragraph with high-level information about aria-at and the plan for data to be available by end of 2023.

Table structure

We will eventually have data for more AT than browsers. So, we may want to have a row for each AT rather than a row for each browser.

Version numbers

We need to include the major version of the AT along with the name of the AT. I don't think that is necessary for browsers on this page.

Test plan status disclosure

We need the option of including data from either candidate or recommended reports. So, we should have a warning disclosure above the table that explains the providence of the data. We can use the same disclosure we have on the aria-at reports site. We still need to write the copy for that disclosure if the plan is a recommended plan. We already have copy on the aria-at reports site for candidate reports.

Report site links

I don't think we want to link to the detail page for the AT/browser because that report page does not include an overview. We'd be taking people from a single number to super low level detail. I am willing to be that most readers wouldn't be interested in that level of that detail. So, the link in each cell should go directly to the summary table for that AT./Browser/Pattern. For example, on the button example page, the JAWS/Chrome cell would link to the heading for JAWS and Chrome on the button results page. I think we should be changing the aria-at site to include that summary table at the top of the detail page, but that is a separate discussion. For now, this is likely the best we can do.

[isaacdurazo]

Note: the mockups above have been updated based on @mcking65's feedback

[giacomo-petri]

Something similar about "Assistive Technologies Support" and how to track changes/inconsistent support/etc. has been discussed in ACT-Rules community group (act-rules/act-rules.github.io#1939). Discussion is still in progress but, even if not required, might be interesting keeping consistency between groups.

Note: candidate report tag label apparently doesn't have a sufficient contrast ratio with its orange background.

[isaacdurazo]

Thanks, @giacomo-petri, you were right. That label didn't have enough contrast. I have updated it now.

I also saw Matt has responded to you on act-rules/act-rules.github.io#1939. I agree it would be good to have consistency.

[sivakusayan]

As someone with a cursory interest in UX I love how clean this looks 🙂

Would it make sense to have the "View Complete Report" button in the embedded version too? I feel like that's something I would want to see if I saw this embedded somewhere. On the other hand, I am also more interested in the technical details of accessibility than most web developers so I'm not sure if that button would just be noise for others.

[a11ydoer]

My only comment was color contrast issue @giacomo-petri raised and it seems that it is taken care of. Thanks @isaacdurazo !

[isaacdurazo]

I think having the "view complete report" button in the embed makes sense, @sivakusayan! I'll update the mockup to reflect that. Thanks for the feedback and sorry for my late response.

[howard-e]

@mcking65 as a follow-up from the CG meeting on Dec 6th, some additional details from the ARIA-AT App side. To support this feature being managed with full editorial control on the APG website, we will be adding a “Copy Embed Code” button on each individual report available on the app's report page.

An example code snippet produced from that would be:

<iframe width="939" height="176" src="https://aria-at.w3.org/reports/embed/command-button?assistive%20technologies=jaws%2Cnvda%2Cvo"></iframe>

The underlying iframe embed would be the following unstyled code snippet which was generated (not final) by the ARIA-AT App. It contains the report’s status (Candidate or Recommended) and disclaimer, the support percentage table and the “View Complete Report” and “Embed” buttons:

<div>
    <div id="embded-report-status-container">
        <div><span>Candidate Report</span></div>
        <div>
            The information in this report generated from candidate tests.
            Candidate aria-at tests are in review by assistive technology
            developer and lack consensus regarding:
            <ol>
                <li>applicability and validity of the tests, and</li>
                <li>accuracy of test results.</li>
            </ol>
        </div>
    </div>

    <table id="embed-report-table">
        <thead>
            <tr>
                <td></td>
                <th>Chrome</th>
                <th>Safari</th>
            </tr>
        </thead>
        <tbody>
            <tr>
                <th><b>JAWS</b> 2022.2207.25</th>
                <td><span classname="progress50"></span><b>50%</b> of passing assertions</b></td>
                <td><span classname="none">None</td>
            </tr>
            <tr>
                <th><b>NVDA</b> 2022.2.3</th>
                <td><span classname="progress50"></span><b>50%</b> of passing assertions</b></td>
                <td><span classname="none">None</td>
            </tr>
            <tr>
                <th><b>VoiceOver for macOS</b> 12.6</th>
                <td><span classname="none">None</td>
                <td><span classname="progress50"></span><b>50%</b> of passing assertions</b></td>
            </tr>
        </tbody>
    </table>

    <div classname="embed-button-row">
        <button>View Complete Report</button>
        <button>Embed</button>
    </div>
</div>

This will allow APG editors to control the iframe embeds which can be placed on the example pages under the designated Assistive Technology Support sections.

cc @s3ththompson @alflennik @evmiguel

[isaacdurazo]

@mcking65, One thing with regard to displaying the AT version, is that we could have testers using different versions of an AT. We would then need a row in the support table for each version.

What do you think about not showing an AT version and using an aggregate average for the passing assertions?

[mcking65]

@isaacdurazo wrote:

@mcking65, One thing with regard to displaying the AT version, is that we could have testers using different versions of an AT. We would then need a row in the support table for each version.

What do you think about not showing an AT version and using an aggregate average for the passing assertions?

AT version numbers are essential. We will show data for only the latest version tested both in APG and in aria-at. We still need to work out how people will drill backward through version history.

[mcking65]

This has been implemented; closing.