This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
"region role " http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-strong-native-semantics
sections are being used a lot without headings even though the spec has in the past encouraged authors to use section for content that would appear in the doc outline. The HTML spec advice has been strengthened it now says authors SHOULD provide a heading, but that probably won't be enough to stem sectionorrhea (example: http://www.awardwinnersonly.com 393 sections 2 headings) it may make sense to make the role mapping contingent on the section having an accessible name (usually provided via a heading, it could also be provided via aria-label, aria-labelledby or title) This would have the effect once implemented of removing noise for users who consume the semantics
Currently, the specs mapping of <section> to region is resulting in a poor user experience. JAWS for example will announce each <section> element in a page as a 'Region'. Previously this had been reserved for ARIA landmark element IIRC. A page may have a menu with 20 heading items, and if it has several <section> elements then this can bloat very quickly with each one being announced. Newer version of JAWS (> 13) may allow the user to navigate to them via the 'Landmark' quick keys, however this doesn't happen with JAWS 13 for example. Meaning the user will have ~ 60 <section> elements announced to them as they navigate (I've seen this in my work). This is a poor implementation of semantics and if continues may devalue them. If nothing else it adds to the 'don't do this as its bad for a11y, even if semantically correct' kind of argument - which none of us really want to have.
(In reply to Joshue O Connor from comment #2) > Currently, the specs mapping of <section> to region is resulting in a poor > user experience. JAWS for example will announce each <section> element in a > page as a 'Region'. Previously this had been reserved for ARIA landmark > element IIRC. > > A page may have a menu with 20 heading items, and if it has several > <section> elements then this can bloat very quickly with each one being > announced. Newer version of JAWS (> 13) may allow the user to navigate to > them via the 'Landmark' quick keys, however this doesn't happen with JAWS 13 > for example. Meaning the user will have ~ 60 <section> elements announced to > them as they navigate (I've seen this in my work). This is a poor > implementation of semantics and if continues may devalue them. If nothing > else it adds to the 'don't do this as its bad for a11y, even if semantically > correct' kind of argument - which none of us really want to have. Hi Josh, note that it may not be a semantically correct use of section: read what the spec says about use of section: http://www.w3.org/html/wg/drafts/html/master/sections.html#the-section-element
Think this is an excellent suggestion. If the browsers only expose the region role when it's been extended by an accessible label, it will help enhance the UX for users of ATs that pick up that information.
(In reply to steve faulkner from comment #1) > This would have the effect once implemented of removing noise for users who > consume the semantics Noise is bad so this seems important. Should the filtering of useless semantics happen in the browser or the AT? How is the noise currently manifested?
(In reply to David Bolter from comment #5) > (In reply to steve faulkner from comment #1) > > > This would have the effect once implemented of removing noise for users who > > consume the semantics > > Noise is bad so this seems important. > > Should the filtering of useless semantics happen in the browser or the AT? > > How is the noise currently manifested? i think the filtering should happen at browser level, its more robust and we can better ensure browsers actually implement the standards, where as AT... Currently JAWS exposes section as a region (as per html spec) and users have reported it as an issue.
All browsers use heuristics to differentiate data tables from layout tables. It may be that they should use some heuristics here, too. Additionally, this is an area where implementations can differentiate themselves. I don't know that the heuristics need to happen in a spec. If you do make some suggestions of when UAs should heuristically hide semantics from an accessibility API, I'd expect them to be RFC-2119 MAY statements, not SHOULD or MUST.
Steve, can you please give details on the proposal? What provides an accessible name for the section? Is it supposed to come from related heading?
>How is the noise currently manifested? See the following page which presents output generated by Jaws and NVDA in Firefox (results are similar with IE). Have not tested with VoiceOver on MacOS. http://www.mit.edu/~rjc/aria/section.html Jaws is the most noisy, producing both a start and end message for every region. It also produces a landmark marking the start of the region, and adds this to its landmarks list. The usefulnes of landmarks is diminished as their number increases, and since many authors are now using section as a stand-in for div, this can completely flood the landmarks list with useless unnamed entries, making the entire list useless for that document. NVDA, the other popular windows screen reader, neither creates start messages for sections, nor does it create a landmark. Essentially, NVDA treats them as divs. >What provides an accessible name for the section? Is it supposed to come from related heading? Accessible names are never recognized by NVDA on sections (nor by any other region roles). Jaws modifies the accessible name on all region roles via aria-label, aria-labelledby, and title, which is the propper behavior as far as I can determine from the spec. Neither jaws nor NVDA handle outlining (as discussed in section 4.4.10 (Headings and sections) of http://www.w3.org/html/wg/drafts/html/master/sections.html#headings-and-sections In my opinion as a screen reader user, neither Jaws nor NVDA handle sections (or regions in general) correctly. - sections should only be mapped to region role if they have an accessible name; - accessible names should be user-definable by aria-labelledby, aria-label, and title on all sectioning elements as defined by the above referenced spec However, according to the spec, and confirmed in the document referenced above, adding role="presentation" to a section tag causes jaws to completely ignore it (i.e. region / region end messages disappear from the virtual buffer and the region is removed from the landmarks list)!! Perhaps this is how the community should remediate this issue until browsers and/or screen readers (specifically Jaws) change the way they handle section.
Commit pushed to master at https://github.com/w3c/html https://github.com/w3c/html/commit/eef0c51bdc2fe70a3bacbc6c3a3af5524d2bfb6a add note for SR implementers about sections see Bug 23545
(In reply to github bugzilla bot from comment #10) > Commit pushed to master at https://github.com/w3c/html > > https://github.com/w3c/html/commit/eef0c51bdc2fe70a3bacbc6c3a3af5524d2bfb6a > add note for SR implementers about sections > > see Bug 23545 as a first step have added recommendation to section/region mapping: Note:It is strongly recommended that user agents such as screen readers only convey the presence of, and provide navigation for section elements, when the section</code> element has an accessible name. Lets see if we can get JAWS to change its behaviour based on a normative recommendation in the spec.
It seems the problem here people started to use section element in means of div element (which is wrong, i.e. an author error), section is mapped to ARIA region what makes AT to announce each section. So we discuss here how to fix author errors. Another example of author error would be what if people started to use role="region" as they use section element. This probably won't happen but it's dual example to what we observe with section element. So we have two alternatives: 1) AT could ignore section with no name (it makes sense if there is no use case for these sections) 2) The browser exposes such section element as ordinal div (Steve's suggestion)
Commit pushed to CR at https://github.com/w3c/html https://github.com/w3c/html/commit/eef0c51bdc2fe70a3bacbc6c3a3af5524d2bfb6a add note for SR implementers about sections
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: partially accepted Change Description: added advice for user agents encouraging them to only expose as region when the section has an accessible name. See Comment 11 Rationale: encourage user agents to provide a better user experience, by not exposing semantic information when it is unnecessary.