Accessibility issue in keyboard nabigation

[kompetenzzentrumgit]

We are teh KOMPETENZZENTRUM DIGITALE BARRIEREFREIHEIT.NRW, we are a digital Accessibility evaluation and testing organization within the Technical University of Dortmund, Germany. We have scientifically evaluated the Accessibility of different H5P elements including Accordion, and we have observed the following points.

• "The problem with the accordions on the H5P side is the focus management for the accordion headings. Normally, the buttons should only catch Enter and Return (and show/hide the sections). In H5P, they also catch the arrow keys, but this is not actually intended (see ARIA Authoring Practices Guide).

Solution 1: Stop intercepting the arrow keys. Then the arrow keys are used for scrolling. Solution 2: Make sure that there is always a focusable element in the displayed content (e.g. a heading with tabindex="0"). This can also be the entire section (tabindex="0" on a section element), but only if it contains no focusable content. Solution 3: Consider scrollbars. This could still be a bit fiddly for keyboard-only (without a screen reader)."

[otacke]

@kompetenzzentrumgit I think that catching the Down Arrow key and Up Arrow key is optional, but completely fine according to the Accordion Pattern of the ARIA Authoring Practices Guide: "

• Down Arrow (Optional): If focus is on an accordion header, moves focus to the next accordion header. If focus is on the last accordion header, either does nothing or moves focus to the first accordion header.
• Up Arrow (Optional): If focus is on an accordion header, moves focus to the previous accordion header. If focus is on the first accordion header, either does nothing or moves focus to the last accordion header.

"

Also catching the Left Arrow key (duplicating the Down Arrow key behavior) and catching the Right Arrow key (duplicating the Up Arrow key behavior) is something that might be unexpected, but that is not what you are referring to here.

[otacke]

@kompetenzzentrumgit I have one more question: What guideline is your "solution 2" based on?

You're requesting to allow setting focus on a non-actionable element by forcing tabindex='0' on it. I think I get your intention (which you unfortunately do not specify), namely to allow tabbing to the content which most likely will be text only. But wouldn't blind users in particular use their "Navigate forward/backward" keys (not to be confused with the Tab key) to read through text and continue reading after a panel was expanded?

Setting tabindex='0' to non-actionable elements usually is not good accessibility practice as far as I know, and there are only a few exceptions such as modal dialogs that require the focus to be set inside the dialog regardless of an actionable element being present or not.

There's nothing said about setting the tabindex the way that you request to in the accordion pattern guideline, and I have also checked some other reference implementations/tutorials, e.g

• https://techservicesillinois.github.io/accessibility/aria-examples/accordion.html and
• http://web-accessibility.carnegiemuseums.org/code/accordions/ and
• https://www.aditus.io/patterns/accordion/ and

none of those forces a tabindex on the panel content.

[kompetenzzentrumgit]

Firstly we want to thank you for a very quick response to our inquiry, however we consider that our explanation of it was not clear enough. We are afraid that we started from the end. Now we would like to describe the accessibility issue we have found in teh interaction with keyboard ()mouse-free.

With keyboard interaction scrolling within expanded longer texts is difficult. Scrolling is not possible within longer expanded text due the system focus Remains persistently on the panel's headings.

This situation causes the following problems:

• Difficulties to navigate between panel headings with arrow keys.
• If a panel is open, the focus still on the panel heading, then scrolling within the text with arrow keys is not possible unless if a link texts or other focusable elements would be within the text).

A very general evaluation can be summarized in the following statement: The accordion can be used well if the user do not require to scroll to read the expanded texts.

[otacke]

@kompetenzzentrumgit That assessment is quite understandable. It would be resolved by completely removing the optional Arrow Key listeners indeed, even though those do not violate the ARIA Authoring Practices Guide. Your other two suggestions are rather workarounds that do come with other drawbacks.

However, I am not a member of the H5P core team by the way, and it's up to them to decide whether they're following your suggestion.