Tab behavior toggle for accessibility

[ksen0]

Increasing Access

To improve accessibility, the code editor on the site does not use tab for indent. This way, tab key can be used for navigation by, for example, screenreaders and other users who rely on keyboards for navigation. You can check out any page with an editable code snippet, and try to use tab both inside and outside the code editor to see what it currently does.

However, tab could be used in the code editor to indent if esc can be used to get out of the editor mode. This would avoid the keyboard trap that was the original accessibility problem (WCAG Success Criterion 2.1.2: No Keyboard Trap), but it's not really intuitive, so it should not be the default behavior.

Most appropriate sub-area of p5.js?

Home

Feature request details

Proposed behavior:

• Current behavior stays as a default, which is tab is used for navigation and not indent
• Under the "Accessibility" tab, there is a new entry, "No tab indent," which is checked by default.
• When this is NOT checked, the user should be able to use tab to navigate into the code editor, and then esc to get out of the code editor. This still avoids keyboard traps.

Previous discussion and further reading:

• Accessibility: resolves #666 #667 and Accessiblity problem introduced on new site's code editors #666
• https://stackoverflow.com/questions/53909477/how-to-handle-tabbing-for-accessibility-with-a-textarea-that-uses-the-tab-button/53910297#53910297

[ksen0]

Picking up on @davepagurek's comments in #667:

I was thinking about your idea to put this behavior somehow under the "Accessibility" toggle, but still keep the default behavior as simple as possible. I was also thinking about something very similar as above, but reversed: "Tab indent" or "Tab to indent" (default unchecked) with an opt-in to the tab+esc behavior.

Alternatively there could be some kind of additional explanation on the code editor to explain tab+esc behavior, which could make it possible to just have 1 default behavior without toggling.

I'm very open to ideas on how this can be as straightforward as possible for users.

[calebfoss]

I want to make sure this discussion also recognizes the work that @katlich112358 did on the old version of the site to address this. They reworked the code editors on the site to use shift+space as the shortcut for tabs and added a text instruction on each editor reading Press Shift-Space to insert tab. beside the edit/reset/copy buttons.

The old site didn't have the Accessibility setting toggles, though, so I think @davepagurek's suggestion to take advantage of that makes sense.

I also want to frame the goal here: accommodating people who prefer tabs over spaces for code indentation and want to use that in the embedded code editors on the site. As someone who does prefer tabs, I can say that I rarely use them in the embedded code editors anyway. In my experience, when one of my students or I edits code on the site, it is to tweak values and see the difference. If I want to do more, I'd usually copy the code into a standalone editor. I suspect that if you conduct usability testing with tasks that involve engaging with the code editors, testers would not be significantly obstructed by not being able to insert tabs with the tab key and may not even notice. In other words, I think the stakes of this issue are very low, and any form of accommodation you decide on here is a nice bonus.

I think the benefit of @katlich112358's solution is that the means to insert tabs is present alongside the editor. Site visitors may not think to check the Accessibility tab for this setting, since many people without relevant disabilities do not know that keyboard navigation is an important accessibility feature.

On the other hand, since the Accessibility settings appear to be stored in local browser data, @davepagurek's solution has the benefit of allowing visitors to change the setting once and keep it that way. Additionally, it means a bit less text around the editor.

Merging the two solutions, you could have a toggle on the editor itself with a concise label like tab or ⇥ and a tooltip that elaborates a bit with something like use tab key to insert tabs. You could store the state in local browser data.

[davepagurek]

Agreed about your discoverability comment, having the toggle (additionally?) next to the editor sounds great.