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
copied from ARIA in HTML issue regarding custom elements:
Per: HTML issue 4658 and ARIA issue 984, it should be specified that a custom element may have no corresponding role (map to generic) or may have a role set by ElementInternals.
If the role is set in that way, and the custom element doesn't merely act as a container for child elements (light or shadow dom) with their own roles, then the listing for the custom element would need to indicate that it either maps to generic, OR the role set by ElementInternals, and to reference THOSE roles for appropriate mappings.
Can we create a separate issue for hgroup so that it is not held up waiting for autonomous custom elements? Is hgroup "Not mapped" everywhere? Does it need to wait for the "If mapped" PR #226?
(For context, I'm hoping to point to hgroup (and slot) from the html spec, but at present, they're missing from html-aam). :)
I do not think #226 should be a blocker here anymore, per my comment today in that issue's WIP PR.
hgroup is not mapped anywhere and may well continue to be unmapped (though impact the heading levels of contained elements) depending on how that gets reworked in the HTML spec.
slot is not mapped, nor should it be.
autonomous custom elements are either role=generic or mapped to the role declared via its ElementInternals.
form associated custom elements should map to the form-related role declared via its ElementInternals.
Activity
scottaohara commentedon Aug 3, 2019
This issue will be picked up once #226 is completed.
scottaohara commentedon Oct 4, 2019
copied from ARIA in HTML issue regarding custom elements:
Per: HTML issue 4658 and ARIA issue 984, it should be specified that a custom element may have no corresponding role (map to generic) or may have a role set by
ElementInternals.If the role is set in that way, and the custom element doesn't merely act as a container for child elements (light or shadow dom) with their own roles, then the listing for the custom element would need to indicate that it either maps to generic, OR the role set by
ElementInternals, and to reference THOSE roles for appropriate mappings.carmacleod commentedon Dec 2, 2019
Can we create a separate issue for
hgroupso that it is not held up waiting for autonomous custom elements? Is hgroup "Not mapped" everywhere? Does it need to wait for the "If mapped" PR #226?(For context, I'm hoping to point to
hgroup(andslot) from the html spec, but at present, they're missing from html-aam). :)scottaohara commentedon Dec 2, 2019
I do not think #226 should be a blocker here anymore, per my comment today in that issue's WIP PR.
hgroupis not mapped anywhere and may well continue to be unmapped (though impact the heading levels of contained elements) depending on how that gets reworked in the HTML spec.slotis not mapped, nor should it be.autonomous custom elements are either
role=genericor mapped to the role declared via itsElementInternals.form associated custom elements should map to the form-related role declared via its
ElementInternals.