Keyboard Shortcut Dialog is Not Accessible via Keyboard Navigation

[Jatin24062005]

p5.js version

No response

What is your operating system?

None

Web browser and version

No response

Actual Behavior

When opening the Keyboard Shortcuts dialog in the p5.js Web Editor, the shortcut keys and their corresponding actions (e.g., Ctrl + / → Comment Line) are not focusable or navigable using the Tab key. This makes it very difficult or impossible for users who rely on keyboard navigation (e.g., those with motor disabilities or who use screen readers) to read or understand the available shortcuts.

Expected Behavior

Each shortcut key and description should be individually focusable using the Tab key (or arrow keys), allowing screen readers and keyboard users to access the information.

Steps to reproduce

1. Open the p5.js Web Editor.
2. Open the Keyboard Shortcuts dialog.
3. Try to use the Tab key to navigate through the list of shortcut keys with Screen Reader.

[dipamsen]

I am not very knowledgable on this topic, but isn't this supposed to be information which is not interactive? Which would make me think that it shouldn't be focusable and tab-navigable. Correct me if I am wrong.

[Jatin24062005]

@dipamsen You're right that the content in the shortcut dialog is informational and not interactive. However, the issue is about accessibility, not interactivity.

For users who rely on keyboard navigation or screen readers, content needs to be focusable or reachable using the keyboard. If it's not, those users can't perceive the information

[dipamsen]

Is that true? According to my knowledge, tab-indexing / focus is only for interactive elements, so that e.g. a keyboard can be used to interact with the site to the same extent as a mouse. Since the content is purely informational, screen readers should be able to access it in the normal document flow (like any non-interactive content). Otherwise we would have every element to be focusable and tab indexable (e.g. each paragraph of text can be tabbed to in a blog/article), which I don't think is the correct experience. (At least I have not seen any such website.)

Could you link any reference/resource about accessibility that supports your claim?

[Jatin24062005]

You're absolutely right — in general, static content shouldn't be made focusable. But in the context of a modal where focus is trapped, if the content isn’t semantically structured (like using lists or tables), then screen reader and keyboard-only users might not be able to access it. That’s why some focusability or semantic enhancement is necessary — not for interaction, but for perception and accessibility.
https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/
https://webaim.org/techniques/keyboard/

we have to find somehow a way to make them readable with keyboard navigation also because these are essential keys and values to enhance user experiences.

[dipamsen]

Thanks for the link, in https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/ it states

If the dialog content includes semantic structures, such as lists, tables, or multiple paragraphs, that need to be perceived in order to easily understand the content, i.e., if the content would be difficult to understand when announced as a single unbroken string, then it is advisable to add tabindex="-1" to a static element at the start of the content and initially focus that element. This makes it easier for assistive technology users to read the content by navigating the semantic structures. Additionally, it is advisable to omit applying aria-describedby to the dialog container in this scenario.

This applies to our case, since the dialog content does include lists and headings. According to the above guideline, it is advisable to add tabindex="-1" to the content in the dialog, and programmatically focus it when the dialog is opened. This will allow the screen reader to semantically navigate through the content in the dialog.

However do note, that this does not affect keyboard navigation in any way. Doing so will not make each individual list item to be focusable/tabbable. tabindex="-1" only makes it so that the element is programmatically focusable, but the element does not appear in the keyboard tab-navigation flow.

Here's a relevant comment about focus on static elements: w3c/aria-practices#2698 (comment)