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
incorrect aria-level on headings? #308
Comments
I wrote that code and will look at it. In general the 'h' elements that are used in the generated content are wrong (top level headings are h2, but the aria-level should be 1). Let me do some digging. It could be broken now. |
thanks! |
I took a look at your spec (and a couple of mine). It seems to me that the aria-level attribute values are correct in that they reflect the level of the sections they are within. For example, in your specification the first section that has a ToC entry is "Requirements for providing text to act as an alternative for images". That section has a ToC number of 1 and an aria-level of 1. A subsection of that section is "Examples of scenarios where users benefit from text alternatives for images", has a ToC number of 1.1, and an aria-level of 2. These are the levels that the PFWG agreed should be used when a document is structured in this way. Is it wrong? |
"These are the levels that the PFWG agreed should be used when a document is structured in this way. Is it wrong?" yes, headings should reflect their outline depth. which in the alt doc, without the aria-level set, they do. |
It isn't that the PF wants anything. They just agreed this was the right structure. You are saying that the "h1" element that is used as a title of the W3C spec is an enclosing "level" for the document? That feels wrong to me. I think in a W3C specification that heading area (the contentinfo section) is data about the document, but it is not an enclosing wrapper. I agree there is an "h1" up there, and that H1 describes the nature of the 'body' but to me that is not the top level. Do you think there is some data somewhere to support your position? I mean, I am happy to make the changes in ReSpec if this is really the community consensus about how W3C specs are structured. It just seems counter-intuitive to me. |
that's what the HTML5 spec says. There appears to be a mixing of the document outline concept and what is represented in the TOC. When an AT for example provides a representation of the Doc outline to a user, it does not ignore headings as the TOC does. |
HTML5 notwithstanding, and possibly independent of this discussion, surely the purpose of the aria-level attribute is to correctly inform the AT of the structure of a document. I get that by default an AT uses the level of an H element to determine its nesting level, but there is no requirement that authors use those H elements in a way that is consistent with the default order is there? Nor is there a requirement that authors use section elements, or even exclusively section elements, to structure their documents. An AT would be challenged to correctly guess the nesting level of sections that were within a bunch of DIVs. Note and Issue titles, for example, also get aria-levels (that are consistent with the other aria-levels currently being provided by ReSpec) and roles of header. Is this an incorrect usage of aria-level? |
the generally accepted advice for use of headings is to provide a h1 for the main page heading and to use h2's to indicate sections, h3 subsections this has been common advice for a long time wcag 1 example http://www.w3.org/WAI/wcag-curric/sam33-0.htm wcag 2 tech example http://www.w3.org/TR/WCAG-TECHS/G141.html |
any progress on this? |
The PFWG Editors met and discussed this today. The consensus of the group is that for table of contents / navigation purposes sections should be at the top level. However, the group also agreed that we should not be overriding the H level semantics. Rather, the sections should be H1. But this is not a battle we are willing to fight today. I will change the code as per your request. The PF Editors have also suggested that the initial H1 and H2 in the document (the ones that appear in the masthead) be annotated such that AT navigation does not consider them to be "headings", since they are not. I am investigating setting a role of presentation on these items so that they are ignored. |
No longer set aria-level on section headers. Fixes w3c#308
Thanks Shane. if the PFWG editors want to meet in member only space and decide on the document semantics for PF specs that is fine by me. But in this case the decisions made were effecting every editor using respec. In regards to "The PF Editors have also suggested that the initial H1 and H2 in the document (the ones that appear in the masthead) be annotated such that AT navigation does not consider them to be "headings'" Please do not implement such a change by default that other users of respec will have to work around implement as a preference that can be enabled by those who agree it is useful and appropriate. Note I am in partial agreement with the issue of heading use in the 'masthead' and made changes to the editors draft of the html spec, so the doc outline for http://www.w3.org/html/wg/drafts/html/master/ |
You would get strong disagreement from the PFWG about such a structure, but You filed a problem report. I took it up with the people who designed the On Wed, Jul 16, 2014 at 2:18 PM, stevefaulkner notifications@github.com
Shane McCarron |
"You would get strong disagreement from the PFWG about such a structure" Suggest you test that assertion on the PFWG public list (http://lists.w3.org/Archives/Public/public-pfwg/), to get a real gauge of the PF thinking on headings. |
looking at http://rawgit.com/w3c/alt-techniques/master/index.html I see aria-level=1 on headings inside a <body><section>
these should be aria-level=2 and correct elements h2 are being used.
example:
<section id="toc">
<h2 id="h2_toc" class="introductory" aria-level="1" role="heading"></h2>
If the correct headings are used for the nesting level, there should be no need to apply aria-level and role=heading.
so it looks like ARIA is being unnecessarily added and breaking semantics in process
The text was updated successfully, but these errors were encountered: