Skip to content
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

Closed
stevefaulkner opened this issue Apr 21, 2014 · 13 comments · Fixed by #325
Closed

incorrect aria-level on headings? #308

stevefaulkner opened this issue Apr 21, 2014 · 13 comments · Fixed by #325

Comments

@stevefaulkner
Copy link

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

@halindrome
Copy link
Contributor

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.

@stevefaulkner
Copy link
Author

thanks!

@halindrome
Copy link
Contributor

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?

@stevefaulkner
Copy link
Author

"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.
body
heading level 1

If the PF want to set heading levels differently from what is advised in HTML5, would appreciate a method to turn off the addition of the role/level attributes in respec

@halindrome
Copy link
Contributor

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.

@stevefaulkner
Copy link
Author

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'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.

@halindrome
Copy link
Contributor

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?

@stevefaulkner
Copy link
Author

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

@stevefaulkner
Copy link
Author

any progress on this?

@halindrome
Copy link
Contributor

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.

halindrome added a commit to halindrome/respec that referenced this issue Jul 16, 2014
No longer set aria-level on section headers.
Fixes w3c#308
@stevefaulkner
Copy link
Author

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.
I would strongly suggest that if the PF editors want to see a change in how W3C specification outlines are structured they bring this up on a public list. (http://lists.w3.org/Archives/Public/spec-prod/)?

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/
is this
<h1>HTML 5.1 Nightly
<h2>Abstract
<h2>Status of This document
<h2>Table of Contents

@halindrome
Copy link
Contributor

You would get strong disagreement from the PFWG about such a structure, but
whatever. I am not here to advocate. I know that you have strong opinions
about A11Y. I am sure you would agree that the PFWG has a substantial
collection of experts on the semantics of ARIA.

You filed a problem report. I took it up with the people who designed the
original implementation. They agreed to your change. You're welcome.

On Wed, Jul 16, 2014 at 2:18 PM, stevefaulkner notifications@github.com
wrote:

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.
I would strongly suggest that if the PF editors want to see a change in
how W3C specification outlines are structured they bring this up on a public
list
. (http://lists.w3.org/Archives/Public/spec-prod/)?

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/
is this

HTML 5.1 Nightly

Abstract

Status of This document

Table of Contents


Reply to this email directly or view it on GitHub
https://github.com/darobin/respec/issues/308#issuecomment-49213276.

Shane McCarron
halindrome@gmail.com

@stevefaulkner
Copy link
Author

"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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants