Allow dropdown inputs to be manually enabled for DnD questions for accessibility

[sjd210]

Adds an accessibility setting to "Enable non-dragging alternative inputs". For now this only affects cloze/drag-and-drop questions, but is defined broadly enough that we can use the same setting for other inputs in the future if they apply (e.g. depending on how we implement reorder question accessibility).

Also adds a Dropdown/Drag and drop override toggle to all question and quiz pages containing these input types in the top right, equivalent to the context switcher on concept pages. The toggle is defaulted to Dropdown if the user has enabled the accessibility setting or is on a mobile device, and Drag and drop otherwise. If manually toggled, this overrides all other settings and the toggled input mode is enabled instead (e.g. allowing drag and drop at xs screens, if wanted).

I'm not 100% confident on things like:

• if we should hide the toggle for logged-in users with the new setting disabled (so they'd see no external change)
• the exact placement of these toggles - there could be an option to hide it? or we could add it to the sidebar instead? 🤷‍♀️

Thoughts welcome!

Also requires https://github.com/isaacphysics/isaac-sops-config/pull/22 for new accessibility setting to work. Merged!

---

Known problem: If a question is using dropdowns on first page load, then the first time drag and drop is switched to the dropzones will not load properly. This is a pre-existing issue (try some incremental page width changes on a live question) but is surfaced a lot more heavily here. This is sure to be some portalling shenanigans, and I don't think we should merge this without fixing it, but the rest is ready to review now.

[codecov]

Codecov Report

❌ Patch coverage is 51.51515% with 32 lines in your changes missing coverage. Please review.
✅ Project coverage is 43.19%. Comparing base (607cd20) to head (4f43a1e).
⚠️ Report is 51 commits behind head on main.

Files with missing lines	Patch %	Lines
src/app/services/accessibility.ts	41.17%	10 Missing ⚠️
...lements/alerts/InaccessibleContentWarningAlert.tsx	41.66%	7 Missing ⚠️
src/app/components/content/IsaacClozeQuestion.tsx	0.00%	3 Missing ⚠️
...pp/components/content/IsaacDragAndDropQuestion.tsx	0.00%	3 Missing ⚠️
src/app/state/selectors.tsx	0.00%	3 Missing ⚠️
...onents/elements/markup/portals/InlineDropZones.tsx	0.00%	2 Missing ⚠️
...ents/elements/panels/UserAccessibilitySettings.tsx	33.33%	2 Missing ⚠️
src/app/state/reducers/userState.ts	75.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2159      +/-   ##
==========================================
- Coverage   43.20%   43.19%   -0.01%     
==========================================
  Files         601      601              
  Lines       25728    25788      +60     
  Branches     8566     7679     -887     
==========================================
+ Hits        11116    11140      +24     
- Misses      14555    14599      +44     
+ Partials       57       49       -8     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jacbn]

This is looking really good! I have one comment here about keeping hooks inside /services but beyond that my only consideration here is where and how we display the toggle.

As we've discussed, perhaps the most important thing for accessibility across the site is that we are consistent in how we surface accessibility features, so that using a new question type does not feel completely alien to e.g. a screenreader user.

Having a toggle at the top (which may be skipped if the user jumps to a specific section via a hash anchor) for just this question type does feel a little specific, though I can see it having value, particularly for tablets. To this end, I'm very happy for this feature to exist in the accessibility settings (and as you mention, it can remain on the page for non-logged in users), but if our plans for accessibility on other question types do not include such a toggle, I think I'd prefer we improve the accessibility on Cloze by allowing click-to-select and click-to-drop, so that we remain consistent in that all questions can be answered accessibly without requiring a toggle elsewhere on the page.

I'd love to be able to ask an accessibility panel about how they feel about which method is most accessible, as I can only base this off being consistent with other questions... :/

[sjd210]

The main changes since last review:

• Move DnD accessibility hook inside /services
• Move "dropdown/drag and drop" toggle inside InaccessibleContentWarningAlert, and colour it to match
  • This allows the flexibility of users being able to both control the default mode and whether they see the toggle separately
  • (I don't think I agree that this is the best choice, but I think this is an acceptable one and that we're not going to come to an easy agreement otherwise)
• Fix portalling issue (🤞) on switching between input modes by putting the main setPortalFuncs() inside a useEffect, giving it the potential to update on every render based on the contents of newPortalFuncs.
• Enable accessibility tags for quizzes
  • (Note: The ViewQuizzes page uses ALVIs but the MyQuizzes page doesn't. The tags will only show externally on ViewQuizzes - perhaps we should amend this)

See commit messages for other small things.