ARIA Landmark Roles and Labeling the Landmark

[nvaccessAuto]

Reported by jongund on 2010-11-10 22:10
Support ARIA labeling techniques for Landmark roles including aria-labelledby and aria-label properties.

The screen reader should first read the type of landmark (main, navigation, search) and then the label content
Blocked by #1354
Blocking #3741, #3746

[nvaccessAuto]

Comment 1 by kennpetri (in reply to comment description) on 2010-11-10 22:40
Replying to jongund:

Support ARIA labeling techniques for Landmark roles including aria-labelledby and aria-label properties.

The screen reader should first read the type of landmark (main, navigation, search) and then the label content

I'm writing to support this functionality. NVDA already supports landmark roles and having it voice the associated labels provides desired context.

[nvaccessAuto]

Comment 2 by jteh on 2010-11-10 22:47
I'd argue there's no need for this. Other users don't see the name of a section unless there's a heading. They know there's a defined section there due to visual styling (e.g. the main section of the page or the banner of the page), but the name of that section should be included in a heading at the top of that section, which eliminates the need to support this.
Changes:
Milestone changed from None to None

[nvaccessAuto]

Comment 3 by jongund on 2010-11-10 23:09
I would say if there are several navigation landmarks of the same kind it will be much more efficient to know the label associated with the section as part of landmark navigation. The use of headers will require two steps for every landmark role and besides the ARIA specs says that aria-labelledby and aria-label need to be supported by Landmark roles. From a practical point of view Legacy websites may have not have header markup, so this would be an easy way for them to provide labels or titles for the Landmark roles to increase accessibility.

[nvaccessAuto]

Comment 4 by rangin on 2010-11-11 16:04
I strongly support this feature.

I am really surprised to see the comment stating that we don't need this feature. The Web applications are becoming richer and more complex filled with widgets. As screen reader user you have very limited access to the web application and the more structural information we can deliver to the user, the more effective we can make their interactions.

Some of us are working with many complex applications with multiple navigations, searches, complementary contents.
Since NVDA can't read the associated labelledBy content for those landmarks, user can't know if he/she is at e.g. primary navigation landmark, second navigation or third navigation landmark. The same is true for complementary landmarks. So the user doesn't know if he/she is at the e.g. news complementary landmark, weather complementary landmark, or other complementary landmarks in the page.

I am very positive that in a few years ARIA landmarks will become the primary mechanism for navigating within the application framework and headings will be used for its original purpose namely structuring the content.

[nvaccessAuto]

Comment 5 by mscott on 2010-11-11 16:57
I agree that sections are usually indicated by visual styling, but I don't think it follows that the name of a section would/should be included in a (visible) heading at the top of each section. In many common designs, the purpose of sections are obvious by their placement/appearance, and visual designers resist adding headings for screen reader users. For example, consider a page with a horizontal list of links across the top and a vertical list of links lower down on the left edge -- sighted users immediately recognize these as site navigation and section navigation. But, to communicate the equivalent information to screen reader users, we (currently) have to rely on the "hack" of using off-screen headings. ARIA labelledby and label give us better means of achieveing this goal -- assuming screen readers support their use, of course.

[nvaccessAuto]

Comment 6 by jteh (in reply to comment 4) on 2010-11-11 20:44
Replying to rangin:

I strongly support this feature.

As a matter of interest, are you an NVDA user?

I am really surprised to see the comment stating that we don't need this feature. The Web applications are becoming richer and more complex filled with widgets. As screen reader user you have very limited access to the web application and the more structural information we can deliver to the user, the more effective we can make their interactions.

The label isn't structural information; the landmark itself provides the structure.

The same is true for complementary landmarks. So the user doesn't know if he/she is at the e.g. news complementary landmark, weather complementary landmark, or other complementary landmarks in the page.

If there's no heading, all users must determine this from the content. I don't see why screen reader users should be any different.

I am very positive that in a few years ARIA landmarks will become the primary mechanism for navigating within the application framework

Very possibly. However, this isn't predicated on landmarks having labels.

[nvaccessAuto]

Comment 7 by jteh (in reply to comment 5) on 2010-11-11 20:53
Replying to mscott:

I don't think it follows that the name of a section would/should be included in a (visible) heading at the top of each section. In many common designs, the purpose of sections are obvious by their placement/appearance...

Right. However, placement alone can't tell you whether it is "News" or "Weather", for example. You determine this from context or headings.

For example, consider a page with a horizontal list of links across the top and a vertical list of links lower down on the left edge -- sighted users immediately recognize these as site navigation and section navigation.

If this distinction is important, that suggests we need more landmarks; sitenav and sectionnav, or perhaps a sub-landmark which indicates extra structural info. I still don't think landmark labels are the correct solution.

But, to communicate the equivalent information to screen reader users, we (currently) have to rely on the "hack" of using off-screen headings.

I agree that off-screen headings are hacky and shouldn't be used.

ARIA labelledby and label give us better means of achieveing this goal -- assuming screen readers support their use, of course.

Here's a practical reason not to implement this feature:

<div role="complementary" aria-labelledby="weatherHeading">
<h1 id="weatherHeading">Weather</h1>
...
</div>

When the user hits this landmark, they are going to hear "Weather complementary landmark heading level 1 Weather". Note the redundancy of Weather in the label of the landmark. Note also that if that label wasn't present, the sighted user would have to determine this from context.

[nvaccessAuto]

Comment 8 by jongund on 2010-11-11 22:46
In your example if you are using landmark navigation I would expect to hear only:
"Complementary Weather"

I think the feature should be minimal, just allow the user to identify the type of region first and then a then just the text of the region label.

If I start to explore the complementary region then I would hear about the header level 1 Weather.

Jon

[nvaccessAuto]

Comment 9 by jteh (in reply to comment 8) on 2010-11-11 22:56
Replying to jongund:

In your example if you are using landmark navigation I would expect to hear only:

"Complementary Weather"

It doesn't work like that in NVDA. Landmarks aren't rendered on their own line in the document, nor should they be given that they're not actually present in the text. Thus, when you navigate, you hear the landmark as well as the first line of the text in that landmark. This is what we do for all other navigation; landmarks are no exception.

I think the feature should be minimal, just allow the user to identify the type of region first and then a then just the text of the region label.

If I start to explore the complementary region then I would hear about the header level 1 Weather.

This is still incredibly redundant. I don't like hearing the same information twice, especially when it can be avoided.

[nvaccessAuto]

Comment 10 by johnfoliot on 2010-11-11 23:12
I too would like to voice my support for this. As the ARIA Spec approaches Recommendation status, it is important that user agents respect the specification as written: there is a very real and negative message sent when user agents don't support things. It tells authors not to bother, so they don't.

As advocates for accessibility continue to promote and encourage usage of ARIA in content producers work flow (including all of the major JavaScript Libraries), those authors should be able to be confident that what they author works - in all browsers, with all AT, and not have to worry that some aspects of ARIA are not supported across the board. A fragmentation strategy does not garner support for a particular software tool, it isolates it.

I ask that you reconsider your decision.

[nvaccessAuto]

Comment 11 by jteh (in reply to comment 10) on 2010-11-11 23:18
Replying to johnfoliot:

I too would like to voice my support for this. As the ARIA Spec approaches Recommendation status, it is important that user agents respect the specification as written

In this case, I very much disagree with the spec, but I'm not involved in the spec group and it's a bit late to change it now.

there is a very real and negative message sent when user agents don't support things. It tells authors not to bother, so they don't.

Personally, I'd argue that authors shouldn't bother using aria-label/aria-labelledby on landmarks. :)

I ask that you reconsider your decision.

If I'd made a final decision, I would have closed this as wontfix. :) In simple terms, if someone wants to implement this, I guess I won't complain given that it complies with the spec, despite the fact that I think it is a terrible idea. However, I do not believe it is high on the ever-growing to do list for us.

[nvaccessAuto]

Comment 12 by benjaminhawkeslewis (in reply to comment 11) on 2010-11-11 23:40
Replying to jteh:

Replying to johnfoliot:

I too would like to voice my support for this. As the ARIA Spec approaches Recommendation status, it is important that user agents respect the specification as written

In this case, I very much disagree with the spec, but I'm not involved in the spec group and it's a bit late to change it now.

Putting the question of whether landmark labels are or are not beneficial, I'd like to suggest it's really not too late to change the spec. Recall the spec is currently still a Working Draft, and that features can still drop out of specs even at the Candidate Recommendation stage (http://www.w3.org/2005/10/Process-20051014/tr.html#cfi). Feedback from implementors should be welcome at public-pfwg-comments@w3.org. A Recommendation that defines features authors can rely on implementors to actually implement is decidedly more useful than one that defines features implementors are planning not to implement!

[nvaccessAuto]

Comment 13 by johnfoliot (in reply to comment 12) on 2010-11-12 00:03
Replying to benjaminhawkeslewis:

Replying to jteh:

Replying to johnfoliot:

I too would like to voice my support for this. As the ARIA Spec approaches Recommendation status, it is important that user agents respect the specification as written

In this case, I very much disagree with the spec, but I'm not involved in the spec group and it's a bit late to change it now.

Putting the question of whether landmark labels are or are not beneficial, I'd like to suggest it's really not too late to change the spec. Recall the spec is currently still a Working Draft, and that features can still drop out of specs even at the Candidate Recommendation stage (http://www.w3.org/2005/10/Process-20051014/tr.html#cfi). Feedback from implementors should be welcome at public-pfwg-comments@w3.org. A Recommendation that defines features authors can rely on implementors to actually implement is decidedly more useful than one that defines features implementors are planning not to implement!

I somewhat agree with Ben, except to say that sometimes implementers need a kick in the pants to deliver what is needed - sometimes the only reason an implementer won't do something is because they have false perceptions of what is and isn't required - especially when it comes to ensuring both Universal Design and Accommodation.

James, I echo Ben's suggestion: fire off an email to PFWG at the W3C - they really do want this kind of feedback now.

[nvaccessAuto]

Comment 14 by jteh (in reply to comment 13) on 2010-11-12 01:57
Replying to johnfoliot:

I somewhat agree with Ben, except to say that sometimes implementers need a kick in the pants to deliver what is needed - sometimes the only reason an implementer won't do something is because they have false perceptions of what is and isn't required - especially when it comes to ensuring both Universal Design and Accommodation.

I've given reasons for why I think this is a bad idea, which you haven't actually addressed sufficiently. You say "false perceptions of what is and isn't required," yet I've demonstrated that this isn't required and that it is redundant. Universal design infers that all users get an equivalent experience. If a sighted user doesn't get a label saying "weather" and has to infer that from context, a screen reader user should do the same. Similarly, a screen reader user shouldn't have to deal with hearing "Weather" twice. If primary and secondary navigation is a common structural concept, then they need separate landmarks.

My primary concern is for screen reader users, since NVDA is a screen reader. Therefore, if I think something is going to be detrimental or superfluous for screen reader users, I don't implement it. It's pointless to follow a spec to the letter if you degrade the experience of your own users in the process. Finally, NVDA never claimed to comply with the ARIA specification; there's nothing in our documentation that says "complies with ARIA 1.0". There probably never will be.

[nvaccessAuto]

Comment 15 by rangin on 2010-11-12 04:11

As a matter of interest, are you an NVDA user?

Yes, I use NVDA but not as my primary screen reader program mainly due to
lack of support for my Braille display.

I have added recently NVDA to the list of screen reader programs that we
usually use to verify
accessibility features that we are recommending to the application
developers whom we are working with.
FYI, most of people who commented on this issue including myself work
locally with their
application developers in their campuses and/or with the
developers whose products we buy for our campuses such as Blackboard,
Desire2Learn, Qualtrics, Ebsco Publishing, and many more.