Tab behavior toggle for website code editor convenience

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:

• https://github.com/processing/p5.js-website/pull/667 and https://github.com/processing/p5.js-website/issues/666
• https://stackoverflow.com/questions/53909477/how-to-handle-tabbing-for-accessibility-with-a-textarea-that-uses-the-tab-button/53910297#53910297

Start with the editable code snippet linked in the issue and inspect the Accessibility tab and current tab-key behavior. Read the discussion in pull request #667 and issue #666 before choosing an approach. Done means the default navigation behavior remains accessible, while the opt-out setting supports editor entry and Escape-based exit without a keyboard trap.