fix: auditory cues to convey information are WCAG 1.1.1 not 1.3.3

[patrickhlauke]

WCAG 2.1 1.3.3. is only scope to instructions that describe other things based on sensory characteristics. The use of audio alone as a cue is not a failure of 1.3.3, but of 1.1.1. Audio-only cues are
non-text content (and time-based media, though relatively short ones). This may not be immediately clear/obvious from the normative wording of the SC (nor the current normative definition of "non-text content"
which gives only visual examples), but referring to 1.1.1 Understanding https://www.w3.org/WAI/WCAG21/Understanding/non-text-content.html see example 8:

An e-learning application

An e-learning application uses sound effects to indicate whether or not the answers are correct. The chime sound indicates that the answer is correct and the beep sound indicates that the answer is incorrect.
A text description is also included so that people who can't hear or understand the sound understand whether the answer is correct or incorrect.

Pull request checklist

• [n/a] Addresses an existing issue: #0000
• Ran yarn fastpass
• [N/A] Added/updated relevant unit test(s) (and ran yarn test)
• [N/A] 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

[msftclas]

All CLA requirements met.

[JGibson2019]

Hi @patrickhlauke, the changes in your PR appear to have introduced some failures for tests. Please make sure that you've merged in the most recent changes from master/have run yarn test, yarn test e2e to see which tests are failing. Then run yarn test:e2e -u and yarn test -u to update snapshots since you've changed text content.

[patrickhlauke]

@JGibson2019 admittedly, i have very little idea here of how the whole thing is set up, but fundamentally: when doing a PR, do you also need to edit the snapshot against which this then gets tested?

[JGibson2019]

@JGibson2019 Jacqueline Gibson FTE admittedly, i have very little idea here of how the whole thing is set up, but fundamentally: when doing a PR, do you also need to edit the snapshot against which this then gets tested?

No worries! When you make a PR it's best practice to run yarn test just to ensure you haven't introduced any failures. Usually, text changes like the ones you introduced can cause snapshot failures (as the text now deviates from what was previously there); the output from running yarn test will usually tell you if any snapshots need to be updated. In your case, it looks like one of the e2e tests we run needs its snapshot updated with the text change and new link your PR introduced. So I would recommend running the commands I mentioned in my previous comment to update snapshots, commit, and push to your branch so the build can run again :) Let me know if you have any questions!

[LiLoDavis]

WCAG 2.1 1.3.3. is only scope to instructions that describe other things based on sensory characteristics. The use of audio alone as a cue is not a failure of 1.3.3, but of 1.1.1. Audio-only cues are
non-text content (and time-based media, though relatively short ones). This may not be immediately clear/obvious from the normative wording of the SC (nor the current normative definition of "non-text content"
which gives only visual examples), but referring to 1.1.1 Understanding https://www.w3.org/WAI/WCAG21/Understanding/non-text-content.html see example 8:

An e-learning application
An e-learning application uses sound effects to indicate whether or not the answers are correct. The chime sound indicates that the answer is correct and the beep sound indicates that the answer is incorrect.
A text description is also included so that people who can't hear or understand the sound understand whether the answer is correct or incorrect.

This change sounds good to me.

[patrickhlauke]

i've tried running those tests, but am getting a boatload of failures on 100s of seemingly unrelated things. wondering if my environment is incorrectly set up ... i'm not much of a CLI warrior.

getting failures for things like:

FAIL  src/tests/unit/tests/common/components/cards/failed-instances-section.test.tsx
  ● Test suite failed to run

    src/common/components/cards/result-section.tsx:13:25 - error TS2307: Cannot find module './result-section.scss'.

    13 import * as styles from './result-section.scss';

[patrickhlauke]

it IS also telling me that 1 snapshot was updated, but can't see anything for me to commit/add to this PR when i do git status

Snapshot Summary
 › 1 snapshot updated from 1 test suite.

Test Suites: 189 failed, 418 passed, 607 total
Tests:       1 skipped, 2964 passed, 2965 total
Snapshots:   1 updated, 336 passed, 337 total
Time:        87.348 s, estimated 92 s
Ran all test suites.

redux@Epimetheus:/mnt/d/github/patrickhlauke/accessibility-insights-web$ git status
On branch auditory-cues-correct-wcag-sc
Your branch is up to date with 'origin/auditory-cues-correct-wcag-sc'.

nothing to commit, working tree clean

[dbjorge]

The failures you're seeing with the unit tests are probably due to not having built (yarn build) before running the tests; perhaps we should add the generate-scss step in as an automatic part of the yarn test command.

The updated snapshot not showing up in git status is confusing and I haven't seen that before; it should be updating a file that git status should be seeing. I don't think it makes sense to bog you down with debugging our build process for such a simple change; I can go ahead and take care of updating the snapshot on your behalf.

[dbjorge]

Thanks for the contribution!

[patrickhlauke]

thanks for the assist there @dbjorge ... i'll have a play with my local environment regardless, hopefully i'll be better prepped for future contributions :)