Edit modal - add accessibility field

[sairina]

Summary

Description of the change(s) you made

Add metadata, strings, tests for accessibility field in the edit modal (DetailsTabView)

Manual verification steps performed

1. Go to the edit modal
2. Look for the new "Accessibility" section below "Audience"
3. Make sure the checkboxes are visually working
4. Use the network tab in developer tools and check in the /sync endpoint that the checked items are being sent in as true when checked and the key is removed when a checkbox is unchecked

Screenshots (if applicable)

Does this introduce any tech-debt items?

This is the first of the new metadata fields to be included in the edit modal.

---

Reviewer guidance

How can a reviewer test these changes?

Run the tests:

• For AccessibilityOptions component using yarn run test-jest contentcuration/contentcuration/frontend/channelEdit/components/edit/__tests__/accessibilityOptions.spec.js

Manually (see also the Gherkin stories for Accessibility here):

1. Log in to Studio
2. Go to the edit modal
3. Look for the new "Accessibility" section below "Audience"
4. Make sure the checkboxes are visually working (they seem to be a bit slow, so any suggestions here appreciated)
5. After checking and unchecking the boxes, click on "Finish" and go back in to edit the resource to make sure what you checked and unchecked are correctly displayed.
6. Make sure to test this with the different resource kinds (video, audio, documents, html5/zip, practice/exercises) and check that what is rendered matches the designs in Figma
7. Make sure that when hovering over the help icon, the longer description appears
8. Use the network tab in developer tools and check in the /sync endpoint that the checked items are being sent in as true when checked and the key is removed when a checkbox is unchecked:

accessibility_labels: {
  some_string: true,
}

References

• Figma design for this feature
• Gherkin stories for this feature
• Addresses Add new metadata fields to Edit Modal #3205

---

Contributor's Checklist

Studio-specifc:

• All user-facing strings are translated properly
• The notranslate class been added to elements that shouldn't be translated by Google Chrome's automatic translation feature (e.g. icons, user-generated text)
• All UI components are LTR and RTL compliant
• Views are organized into pages, components, and layouts directories as described in the docs

Testing:

• Code is clean and well-commented
• Contributor has fully tested the PR manually
• If there are any front-end changes, before/after screenshots are included
• Critical user journeys are covered by Gherkin stories
• Any new interactions have been added to the QA Sheet
• Critical and brittle code paths are covered by unit tests

---

Reviewer's Checklist

This section is for reviewers to fill out.

• Automated test coverage is satisfactory
• PR is fully functional
• PR has been tested for accessibility regressions
• External dependency files were updated if necessary (yarn and pip)
• Documentation is updated
• Contributor is in AUTHORS.md

[rtibbles]

A couple of comments, but this is looking pretty damn close to perfect, code wise!

[sairina]

Noting that there's a lag between when a user clicks on the checkbox and when the UI shows that the checkbox is checked. Not sure where this is coming from, but would appreciate any insight here.

[rtibbles]

lag between when a user clicks on the checkbox and when the UI shows that the checkbox is checked

My guess would be that it's an issue with data propagation, and the data not being as optimistically updated as we want. Can take a look locally.

[rtibbles]

Manual testing checks out - the reported input lag seems to be a result of an 18 month old unreported bug, which I will fix in a follow up PR.