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
{{ message }}
Repository navigation
Clarify mapping of a ‘generic’ element to the accessibility API in ARIA spec #1829
The ARIA spec (https://www.w3.org/TR/wai-aria-1.2/#generic) describes a ‘generic’ element as a container with no semantic meaning on its own, and it also indicates generic elements are exposed in accessibility APIs to assistive technology. It is understandable if a generic element has a native attribute (such as tabindex=‘0’) or a global aria attribute (e.g., aria-live) so such state or property can be provided to an AT. However, for a generic element (e.g., div) without any native semantic or aria attribute (including one that can exclude the element from the accessibility tree), such as <div> a div </div>, if it maps to the accessibility API, what semantic meaning in the generic element is conveyed to an AT? If not mapped over, the spec should be clear on this.
During our test, we noticed that Chrome displays a ‘generic’ role in the accessibility tree only if the element is in focus (e.g., with tabindex=‘0’) or with an accessible name (title attribute).
Please clarify the mapping of the ‘generic’ role.
Link to the version of the specification or documentation you were looking at at.
Also related to #1454, since the mapping of otherwise-generics that get focus or have e.g. aria-live, aria-label, etc. could affect how they are treated inside composite widgets.
I think a div should only be generic if it needs to be in the accessibility tree (focusable, target of aria-owns, etc). Otherwise, a div should have no role (or role=presentation).
It seems a bit weird for ARIA to introduce a role that is sometimes in the accessibility tree but sometimes not. It makes defining things like Owned Child much easier if the spec doesn’t need to special-case generic, because of this weird behavior.
Graphics ARIA and the SVG AAM describe a particularly complicated relationship between SVG/graphic content and implicit generic and presentation roles. I'd hope this could be simplified if generic were more clearly defined.
Activity
jnurthen commentedon Oct 13, 2022
@schne324 can you please give your opinion on this
smhigley commentedon Oct 19, 2022
Also related to #1454, since the mapping of otherwise-generics that get focus or have e.g.
aria-live,aria-label, etc. could affect how they are treated inside composite widgets.schne324 commentedon Oct 19, 2022
I think a
divshould only begenericif it needs to be in the accessibility tree (focusable, target of aria-owns, etc). Otherwise, adivshould have no role (orrole=presentation).It seems a bit weird for ARIA to introduce a role that is sometimes in the accessibility tree but sometimes not. It makes defining things like Owned Child much easier if the spec doesn’t need to special-case
generic, because of this weird behavior.medeaoblongata commentedon Oct 20, 2022
Graphics ARIA and the SVG AAM describe a particularly complicated relationship between SVG/graphic content and implicit generic and presentation roles. I'd hope this could be simplified if generic were more clearly defined.
scottaohara commentedon Oct 21, 2022
ARIA didn't introduce this behavior.
pkra commentedon Jun 28, 2023
@scottaohara could this move to html-aam or can we close it in favor of the discussions there, e.g., w3c/html-aam#454, w3c/html-aam#489.
scottaohara commentedon Jun 28, 2023
@pkra, i would submit this is resolved by #1949 -= which resolves html aam 489
pkra commentedon Jun 28, 2023
Great! I've edited the top card there to automatically close this one upon merging.
Clarification for exposure of generic elements (#1949)
Clarification for exposure of generic elements (#1949)