Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

legend and label element mappings #427

Closed
scottaohara opened this issue Jul 9, 2022 · 2 comments
Closed

legend and label element mappings #427

scottaohara opened this issue Jul 9, 2022 · 2 comments

Comments

@scottaohara
Copy link
Member

scottaohara commented Jul 9, 2022

Questions:

Do we need there to be a specific ARIA role for these elements?
Or, is there a consolidation around a single ARIA role that could be done instead? Would there be ramifications to this?

More info:

This issue moves the discussion about these elements from #373 to here.

Core AAM has mappings for legend and label roles, but these roles were not included in ARIA. The mappings of these two are identical to each other, which makes me question the need for both.

In HTML, legend, label and caption all serve similar purposes - each used to allow for a visible text label to be associated with specific elements (fieldset, labellable form elements and tables, respectively). They each have their own capabilities/requirements in how these elements become associated with the elements which they label/name.

The difference in how these elements behave is that a legend has special quality where if a fieldset is disabled, any controls within the legend will not be disabled.

A label is a clickable element which automatically moves focus to its associated form element, if the element is focusable (not all labellable elements are keyboard focusable).

A caption has magical table super powers and will automatically render as the first element of the table, regardless of where it is nested within the table markup. From what I recall, screen readers (particularly jaws/nvda) don't always allow direct access to the caption if navigating in 'scan' mode. Additionally, Firefox has made the odd choice to not allow keyboard focus to move to interactive elements within a caption - though nested interactive elements within a caption are allowed (i say choice because this behavior has been around for so long and commented on, that if it is a bug, then they clearly don't seem to want to fix it?)

Note: a caption role is not exclusive to a table, as it is also the mapping for a figcaption and can be used within a group (specifically in the context for allowing an element containing text to exist within a pattern that would have otherwise only allowed for interactive roles for the parent composite widget role - e.g., listbox, menu).

@scottaohara
Copy link
Member Author

Core aam will be removing the mappings for these 'roles'

@scottaohara
Copy link
Member Author

Core AAM has removed the legend and label roles.

At this point, I don't think there's much value in adding a role for these elements unless ARIA were to pick back up the idea automatic naming associations (e.g., naming by encapsulation). Closing for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant