NVDA 2017.3
Section element with aria-labelledby="heading-id" should not read heading text twice.
Consider the following markup:
<section aria-labelledby="my-section-heading">
<h2 id="my-section-heading">My Section</h2>
</section>
This defines a landmark region because it has an explicit label. When the user navigates to the region using D or Shift+D, the section label is spoken, followed by the heading text, as follows:
"My Section region My Section heading level 2".
With longer heading text and several regions on a page, the redundancy is really noticeable.
Could you explain the use case further? What information does the section add that the heading does not?
The aria spec seems to allow for this, this section tag only becomes a region landmark because it has a aria-labelledby attribute. However, I don't see how the inclusion of the word region provides any further semantic value over a heading level 2 that covers the same area of the document.
Given that NVDA users can navigate by heading, and could easily infer that each heading level 2 is a descriptor for all content until the next heading level 2, does this achieve the same result?
Putting this another way, assuming that the next heading level 2 is also the start of the next section then what does the announcement of region provide?
Perhaps that assumption is wrong, and there are multiple heading level 2 elements in this section. The question becomes, what is so special about this first one? How would a visual user identify it as being the heading / descriptor for this region of the document.
After saying all that, if a user was encountering something like this, I agree it is not ideal. To handle this situation ideally we would drop the labelledby attribute when landing on the element referred to by the labelledby attribute. As I understand, it would be some work to achieve this within NVDA.
Cases to consider:
The expected output for navigating by landmark should match the expected for navigating by heading.
@carmacleod commented:
With longer heading text and several regions on a page, the redundancy is really noticeable.
NVDA's interpretation of how ARIA-labelledby is handled in this example is correct. Consider whether you need multiple
A similar pattern can now be observed in Slack, where each landmark like "Message header banner landmark" or "Message list main landmark" is labelled by a heading 1 element, so NVDA speaks "Messages list main landmark, Messages List Heading level 1".
@PratikP1 Here is an example page where the 4 sections have headings, and I think it would be nice if NVDA would not read the heading twice, when pressing 'h':
(PS I might remove the aria-labelledby attributes from the
I strongly suggest that NVDA smartly avoid reading the heading contents the second time if they were already read out once due to the containing landmark's aria-labelledby.
Dropping labelledby from landmarks is undesirable because we'd like the presence of their labels in the Landmarks List which can be brought up via _Insert + F7_
cc: @jcsteh
Dropping
labelledbyfrom landmarks is undesirable because we'd like the presence of their labels in the Landmarks List which can be brought up via _Insert + F7_
Do they really need to be landmarks if they have headings?
I strongly suggest that NVDA smartly avoid reading the heading contents the second time if they were already read out once due to the containing landmark's
aria-labelledby.
I don't think anyone is questioning the fact that duplicate reading is annoying. The problem with removing duplication is that there has to be a choice of what to sacrifice. There is almost always a negative consequence when a screen reader tries to be "smart". Using the example from the issue description:
"My Section region My Section heading level 2"
So let's get rid of the heading:
"My Section region"
Now the user isn't aware there is a heading in that place. Worse, if the user starts cursoring, they'll actually be inside the heading, yet we actually didn't read the heading.
Or perhaps we can get rid of the region:
"My Section heading level 2"
Now the user isn't aware there is a region. That means they don't know they can navigate by region, for example.
Either way, the user loses information that might at some point be useful to them.
Hi, all. I figured I'd better jump in here. :)
Please note that I opened this issue before I understood the difference between landmark regions and sections. :)
When I finally "got it", I wrote down this list of points:
aria-labelledby="id-of-heading-child".Those points, and others, are captured in ARIA Practices Guide issue 575: "Draft guidance to help authors understand the difference between landmark regions and outline sections". I encourage you to read through that issue (sorry, it's longish because there's a lot there).
So, back to the current issue.
@jcsteh, would you say that creating a landmark using aria-labelledby pointing to a heading, as in the original description above (and pasted again below for convenience), is something that authors should be discouraged from doing?
<section aria-labelledby="my-section-heading">
<h2 id="my-section-heading">My Section</h2>
</section>
i.e. Perhaps the APG guidance should suggest using a span instead of a heading when creating a landmark? Very interested in your opinion here. We need to tell authors to "do the right thing", but it's not always crystal clear what "the right thing" is. :)
My personal opinion is that there shouldn't be a labelled region at all if
the section has a heading. I'd argue it's redundant. If the user wants to
navigate to the section, they can navigate by heading. The only reason to
have a labelled region is if there isn't a heading, which can happen where
the purpose of a section is obvious visually but not semantically.
Using a span instead of a heading doesn't solve the problem because the
span will still be read as content (so there's still duplication). It just
won't be reported as a heading. It also creates a new problem, which is
that users can't navigate there by heading any more... and I think users
are more likely to navigate by heading than by landmark.
I don't think anyone is questioning the fact that duplicate reading is annoying. The problem with removing duplication is that there has to be a choice of
what to sacrifice. There is almost always a negative consequence when a screen reader tries to be "smart". Using the example from the issue description:
"My Section region My Section heading level 2"
The "obvious" answer would seem to be to separate consideration of the element
text from the element itself.
If you have:
"My Section region"
"My Section heading level 2"
You cut that up, so you have:
"My Section"
"region"
"My Section"
"heading level 2"
So now we have two duplicated pieces of descriptive text, and two element
identifiers.
That would seem rather easy to collapse: the description is one thing, and you
speak the elements in containment order. The end result being something like:
"My Section heading level 2 region"
Or, alternately:
"region My Section heading level 2"
Although I think the latter breaks the paradigm.
I have to agree with @XLTechie here. Separating role text from role itself seems to be most logical solution. The same pattern can be observed in Moodle (ad least in the version used at my university) when course is divided by weeks.
@lukaszgo1 I don't think this is possible in all cases but I agree this would be somehow an interesting approach. If i understand correctly, @XLTechie proposes to suppress the reporting of the label of the landmark or region and report only the element type if, and only if there is already a heading in the landmark with the labelledby ID, similar text.
I think this also applies for table titles, lists etc which have labels similar to the landmark or region label and are associated with eachother via the ID. This behavior is not limited to headings only.
In this case the expected reporting would be "region my section heading level 2".
@jcsteh I understand your aspect, but how about very complex pages where you have lots of headings? Navigation by regions or landmarks would be much more efficient if implemented correctly.
I think web autors would have much more flexibility in such cases if NVDA could detect similarities in a smarter way.
by the way, a simple test page is google search. Pressing e in browse mode will bring you to the search field. NVDA reports "search landmark search combo box is editable search.
It would be enough if NVDA reports "landmark search combo box is editable" because the labels are similar in this case.
I believe this must have been fixed at some point - thank-you!
Wikipedia has a lot of navs that have a heading used for the landmark label.
Whether using landmark navigation (d and shift+d) or heading navigation (h and shift+h) or browse mode (up/down arrow) to go through these navs, NVDA reads the region/heading label only once. Nice!
For example:
navigation landmark Contribute heading level 3
navigation landmark Tools heading level 3
navigation landmark Print/export heading level 3
navigation landmark In other projects heading level 3
Also, here's a completely fake example app that I created for testing and added at least 1 of each type of landmark. The regions and asides are marked up with aria-labelledby pointing to a heading, and if I go through those using either landmark or heading navigation or in browse mode, there's no redundancy spoken on any of the landmark types.
For example, with landmark or heading navigation:
region Store heading level 2
region Playground heading level 2
complementary landmark Advertisement heading level 2
complementary landmark Sign up for our Newsletter heading level 2
Or, moving forward in browse mode:
region heading level 2 Store
out of region region heading level 2 Playground
out of region complementary landmark heading level 2 Advertisement
complementary landmark heading level 2 Sign up for our Newsletter
So I think this issue can be closed.