-
-
Notifications
You must be signed in to change notification settings - Fork 642
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
Section with heading child and aria-labelledby reads heading text twice #7823
Comments
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 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? Perhaps that assumption is wrong, and there are multiple 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 Cases to consider:
The expected output for navigating by landmark should match the expected for navigating by heading. |
@carmacleod commented:
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 Dropping |
cc: @jcsteh |
Do they really need to be landmarks if they have headings?
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: |
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:
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. <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. 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. |
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. |
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. For example: 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: Or, moving forward in browse mode: So I think this issue can be closed. |
NVDA 2017.3
Section element with aria-labelledby="heading-id" should not read heading text twice.
Consider the following markup:
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.
The text was updated successfully, but these errors were encountered: