Accessibility: resolves #666

[calebfoss]

Resolves issue #666

[davepagurek]

After reading the CodeMirror tab handling docs you linked and stackoverflow threads like this https://stackoverflow.com/a/53910297, how do you feel about continuing to handle tab in the code editor, and documenting its escape-tab behaviour with an element + linking it to the code editor with aria-describedby? Does that adequately give screen reader users an escape hatch while also providing the unfortunately pretty common behaviour of using the tab key in code editors to indent? I'm far from an expert here, just trying to see if there are solutions that balance expectations from all users, but it could be that there isn't a way to have it both ways, so let me know if there might be other pitfalls!

[calebfoss]

Thank you for checking out those docs and sharing your thoughts, @davepagurek!

Yes, you could go the route of defaulting to tab for indent and then instructing the user how to switch back to keyboard navigation as you described. One aspect I want to note is that keyboard navigation is not exclusively used by people using assistive tech. For example, a person may have a disability that impacts their ability to use a mouse but does not affect their ability to see the page content. For this reason, the instructions should be visible (not that you suggested otherwise, just want to note that).

When @katlich112358 and I discussed this during their GSoC project, we came to the conclusion that an accessibility-first approach would be best for this project. We felt that keyboard navigation should be a priority over using the conventional tab key for inserting tabs into example code.

[davepagurek]

That prioritization makes sense to me. One other possibility could be defaulting to the behaviour in this PR, and possibly adding a toggle for the tab behaviour somewhere (maybe where we have the monochrome and reduced motion toggles?) for people who want tab to indent.