How do we handle empty tabpanels? · mdn/content#30470

(0 commentaires) (0 réactions) (0 assignés)Markdown (22 427 forks)batch import

Content:Accessibilityeffort: smallgoal: best practiceshelp wanted

Métriques du dépôt

Stars: (8 900 stars)
Métriques de merge PR: (Merge moyen 7j 3h) (147 PRs mergées en 30 j)

Description

MDN URL

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/tabpanel_role

What specific section or headline is this issue about?

No response

What information was incorrect, unhelpful, or incomplete?

What do we do in the case of empty tabpanels? Do we still keep the empty tabpanel container there, focusable, only for the user to focus on what is essentially an empty div? Do we have to add an aria-describedby attribute to the tab button associated with the empty panel to convey that tab has no content at the moment?

What did you expect to see?

I was expecting to see an example of a tab component that also has the "empty tab" situation taken into account. In some applications, tab contents are dynamically generated and sometimes a tabpanel may be empty if there is no database entry to populate the tab.

I would expect that we would mark the empty tab visually (In our case we used bold for filled tabs and regular font weight to convey empty tab). However, it is not clear to us how to handle this use case correctly from a Tab order + Programmatic accessibility standpoint. What is appropriate? An aria-state on the tab button? Do we remove the empty tabpanel entirely, or do we have to keep is and force users to tab through it even if empty?

Do you have any supporting links, references, or citations?

Our tabs component mirrors this implementation, which is why we found it confusing that it does not address the empty tabpanel situation. https://www.w3.org/WAI/ARIA/apg/patterns/tabs/

Do you have anything more you want to share?