You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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.
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
andlabel
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 agroup
(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).The text was updated successfully, but these errors were encountered: