Heading name does not consider content #280
Comments
|
This also applies to Grouping Content like |
|
True. But I'm rather happy that a Actually, a
|
|
A distinction may be made between content in the element and labeling of the element. For example, in Chrome labeling these elements with aria-label, JAWS only outputs the text content when reading with a virtual cursor (and not the aria-label), only the aria-label for tab navigation (and not the text content). Contrary to the specification, the title attribute is never output as a label, but only as a description while tab navigation and not at all when reading. See https://codepen.io/jaws-test/pen/gOpbOdw I am not sure whether the specification is inadequate here, or whether Chrome and JAWS are not implementing the specification correctly or whether the different output of name and content is so desired depending on the navigation mode. At least I think it's very confusing ... |
|
@Jym77 appreciate the issue. we need to update this section to add some clarity as some elements that are considered grouping or sectioning elements should allow name from contents (e.g. headings), while others ( |
|
Related: w3c/aria#1054, #160 |
As far as I can follow, the Accessible Name computation of heading elements (
<h1>, …) follows Section and Grouping Element Accessible Name Computation which is:aria-labeloraria-labelledbytitleThus, an element like
<h1>Accessible names are cool</h1>has neitheraria-label,aria-labelledbynortitleattribute and will have no accessible name. It seems that it should get an accessible name from content (and that is what UA and AT are doing as far as I can tell).It make sense that other Section elements (e.g.
<body>) don't get their name from content as it would get somewhat crazy… But for<h1>-<h6>element, it looks like a specific case should be added, allowing name from content.The text was updated successfully, but these errors were encountered: