Tab behavior toggle for website code editor convenience

[ksen0]

Increasing Access

The goal of this feature is to "accommodate people who prefer tabs over spaces for code indentation and want to use that in the embedded code editors on the site" (see longer comment by @calebfoss below). The default behavior, where tabs are not used for indentation, is essential for accessibility, so any implementation of this convenience feature should not conflict with that behavior.

As a current accessibility feature, 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. Other solutions are also in the discussion below.

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.

See also other ideas and solutions in the discussion below. Mainly, this convenience feature should be visible/available, but not conflicting with accessibility requirements.

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.

[ksen0]

Thanks for the additional context @calebfoss; I've edited the main issue text.

Since it is a nice to have feature, with a lot of concrete implementation ideas and notes, I thought it might be an alright candidate for "Good First Issue." that way even if it does not itself improve accessibility (actually as you correctly point out it should mostly add a nice feature without making the website inaccessible), working on it can be good for learning about the Accessibility toggle and testing the website with accessibility in mind. That's why I added "Accessibility" to it too, but I'm totally open to revising this.

[dsaw]

Hello! I am a full stack dev with a background in usable/accessibility sites.
I looked and read through the feature and would love to explore more about it.

1. I was checking the p5.js code editor current behavior, and I see that the tab was indenting by default in the code editor, while escaping caused it to leave the indent mode and allow tabbing through the elements. I guess this is the expected behaviour?
2. Having an option "Tab to indent" under accessibility in settings would be great as you already elaborated for more options to the user. Having an option on the code editor itself would be nicer, though to place it in an appropriate and non cluttered manner would be something to think about. I can think of placing it next to the Auto-refresh checkbox, if we don't want to introduce another context menu. Another way might be to allow a right click context menu and add options in there, but it might not be the most accessible component and it is non obvious for any user to figure out.
3. Unrelated to this issue, I notice when I tab through various items on the main code editor page and settings modal, it doesn't seem to cycle through all elements or give visual indication. This is an accessibility issue, if there is another place to report it I can do so. I would be looking forward to discuss ways to tackle such accessible issues if possible.

Update:
I think it would be a good idea to consider this for the code editor (editor.p5js.org) itself also, as the semantics are similar if not identical being a code editor. Could invert the defaults to allow tabs for editing, as it is a editor the users can actually develop their sketches from scratch compared to the embedded code editors. Or to keep consistency the defaults for both could be kept the same.