fix: Show user an "Assessment saved" dialog after they save the assessment

[katydecorah]

Details

This pull request will add an Assessment saved dialog after the users saves an assessment. In the dialog, the user can click "Don't show again" to dismiss the dialog. Like the tab stops dialog, they can reset this value from the settings panel.

The image below shows the "Assessment save dialog" with the option to "Don't show [dialog] again" and "Got it" button to dismiss the dialog:

The image below shows the settings panel, where the user can toggle to enable the save assessment dialog:

When building this feature, I followed the patterns with the tab stops dialog. I found one small improvement with the tab stops dialog that I made with saved assessment: use the Stack component to visually line-up the Do not show again and Got it buttons in the dialog footer. The table below shows screenshots of the current tab stops dialog and proposed:

Current	Proposed

Motivation

Addresses #5608

Context

Pull request checklist

• Addresses an existing issue: [Usability] Save and Load assessment dialog #5608
• Ran yarn fastpass
• Added/updated relevant unit test(s) (and ran yarn test)
• Verified code coverage for the changes made. Check coverage report at: <rootDir>/test-results/unit/coverage
• PR title AND final merge commit title both start with a semantic tag (fix:, chore:, feat(feature-name):, refactor:). See CONTRIBUTING.md.
• (UI changes only) Added screenshots/GIFs to description above
• (UI changes only) Verified usability with NVDA/JAWS

[karanbirsingh]

I haven't seen these fluent-UI hook utility functions before! I understand it now but had to trace it at first. I think(?) this is the first usage of fluent-ui/react-hooks so we might consider a quick ping to interested web-folks to validate that there are no concerns. I'm good either way 🙂

[dbjorge]

At our lowest supported width (1280px wide by 400% zoom), the "Don't show again" text reflows kind of awkwardly:

Ideally:

• The checkbox label shouldn't be right-aligned
• The checkbox should be vertically centered with the wrapped label text
• There should be some margin in between the label text and the "Got it" button

[dbjorge]

The NVDA+Edge behavior for this new dialog feels a bit awkward because the announcement of the dialog gets talked over by the browser's announcement of the download completing; the resulting readout feels to me like it's implying that our dialog controls (the "don't show again" and "got it" controls) are elements of the browser's file download UX, not a page-specific dialog.

@RobGallo, would you mind evaluating the new dialog for usability with your JAWS setup?

[dbjorge]

Left a few comments on usability/UX of the new dialog, will take a look over the code once we've nailed down the user experience

[katydecorah]

I received @RobGallo's evaluation (a few days ago, I was focused elsewhere😅) in which he agrees that the text is confusing, but comprehendible given the constraints that we have.

Another I option I explored was the downloads.onChanged event. The component would listen for when the file downloaded and then trigger the modal. When testing with NDVA, the dialog is announced. The implementation could something like:

React.useEffect(() => {
    browser.downloads.onChanged.addListener(handleDownloadedAssessment);
    return () => {
        browser.downloads.onChanged.removeListener(handleDownloadedAssessment);
    };
}, []);

function handleDownloadedAssessment(event) {
    if (event.state && event.state.current === 'complete') {
        props.deps.detailsViewActionMessageCreator.saveAssessment(event);
        if (props.userConfigurationStoreData.showSaveAssessmentDialog) {
            showDialog();
        }
    }
}

However, this API is limited to chromium and requires manifest.json "downloads" permission. It's not clear to me if either of those are dealbreakers (or if we prefer not to use an event listener). @dbjorge what you think about using the downloads.onChanged here?

[dbjorge]

Thanks for investigating the AT behavior with Rob, Katy! Per our discussion offline, I don't think the issue with the AT reading is enough to justify a new permission on the app, even if it does read a bit awkwardly.

Reviewed the code, left a few suggestions inline.

[dbjorge]

LGTM!