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.

[nvaccessAuto]

Comment 16 by rangin on 2010-11-12 04:23

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.

Other screen programs allow a great degree of customization. NVDA offers some level of customization but not nearly as other screen reader programs. I think The amount of the information can be customized based on user's preferences. For example, if someone decides navigate using the landmark command, it might not be necessary to provide the heading informations. As you know Jaws is resolving this issue by providing both landmark and heading information in two different block of texts. I don't think it is a better solution but I think if you allow users to customize the amount of the information for landmarks/heading might be a better solution.

[nvaccessAuto]

Comment 17 by rangin on 2010-11-12 04:31

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.

I hope you understand that the goal is here to make NVDA even a better and reliable screen reader. I am new to this list. Do you have any weekly, bi-weekly, or monthly teleconference where you discuss the issues? Maybe we can communicate better that way. If yes, can you provide info about your next meeting? If not, will you be able to participate in a teleconference if I set it up?

[nvaccessAuto]

Comment 18 by jteh (in reply to comment 17) on 2010-11-12 05:22 Replying to rangin:

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.

I think The amount of the information can be customized based on user's preferences.

Configurability isn't the correct solution here. The point is that there should not be redundant information in the first place.

Replying to rangin:

I hope you understand that the goal is here to make NVDA even a better and reliable screen reader.

Perhaps, except that no one has actually provided a really valid use case that isn't redundant or makes the experience different between screen reader and non-screen reader users. Put another way, I haven't seen how this will be useful as opposed to pointless extra verbosity.

I am new to this list. Do you have any weekly, bi-weekly, or monthly teleconference where you discuss the issues?

Not at present.

Anyway, I've said my piece on this; see comment:11.

[nvaccessAuto]

Comment 19 by vtsaran on 2010-11-12 06:38 I think this is a tricky one. I agree with Jamie that the ROLE is not an appropriate classifier here but, considering the history of the ARIA spec, it is understandable why the implementers went this route -- namespaces. Surely, something like "landmark=Weather" would have been a better approach. However, I will also say that an ability to label the landmark is very important even if optional. For example, the heading may title a particular section of the page while a related landmark may begin the text for this section. In between the heading and the text the implementer may decide to place relevant links, videos, slideshows etc. In the age of aggregated content and SEO tecniques, this is a widely seen scenario and is here to stay. See http://news.yahoo.com as an example, but there are many to go round. I don't think developers should abuse labeling landmarks though.

[nvaccessAuto]

Comment 20 by benjaminhawkeslewis on 2010-11-12 06:43 Replying to jteh:

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.

If it's a lot easier for a sighted user to do this (i.e. with a glance), is that really an equivalent experience?

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.

Maybe. But there is a risk of defining too many landmark types for authors to remember, and yet still map inadequately to authors' intended meanings. Labels can communicate distinctions more precisely. At any rate, "primary" and "secondary" is not a good enough differentiation for many sites I've worked on ("network", "site", "section", "subsection" might be better).

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.

Strictly speaking, I think ARIA does not impose any conformance requirements on consumers of accessibility APIs.

[nvaccessAuto]

Comment 21 by benjaminhawkeslewis (in reply to comment 18) on 2010-11-12 06:50 Replying to jteh:

Perhaps, except that no one has actually provided a really valid use case that isn't redundant or makes the experience different between screen reader and non-screen reader users. Put another way, I haven't seen how this will be useful as opposed to pointless extra verbosity.

I agree that when reading linearly and the context can be inferred from the first text in the landmark, the label might be "pointless extra verbosity".

But I don't think this is the case when listing landmarks in a element list or jumping from one landmark to another. Sighted users can differentiate landmarks at a glance. If you provided any label annotation (or in the absence of a label annotation but where a heading, legend, or caption is the first text in the landmark, that element content) in the element list and when jumping around the page, that would allow users to differentiate (for example) different varieties of navigation just like sighted users do - without breaking out of the list or the jump cycle. This levels the playing field. What do you think?

[nvaccessAuto]

Comment 22 by jongund on 2010-11-12 15:12

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

or

<div role="complementary" aria-label="Weather">
<h1>Weather</h1>;
...
</div>

There is also the use of "aria-label" attribute to provide a label. The "aria-label" attribute provides a simple way to label a region without referencing any other elements.

In the example above I would expect the screen reader to just render the text content "Complementary Weather". No information about the H1 would need to be rendered. If the aria-labelledy or aria-label were NOT present and there is a heading in the region, then NVDA could use the heading as the label would be a nice feature. But I again I would suggest only using the text content of the heading and not render information about the heading level.

There is also just the generic landmark of role="region", which would need a label for people to describe it.

<div role="region" aria-label="Weather">
<h1>Weather</h1>
...
</div>

or

<div role="region" aria-labelledby="weatherid">
<h1 id="wetherid">Weather</h1>
...
</div>

or

<div role="region" aria-labelledby="weatherid">
<div class="topic" id="wetherid">Weather</div>
...
</div>

or

<div role="region" >
<h1>Weather</h1>
...
</div>

This I would expect NVDA to read these examples as "region weather" when landmark navigation is used to explore a page.

Providing a list of regions would be similar to providing a list of headings or form controls, and labeling the regions/landmarks is a powerful way to provide the user context when the same landmark is used more than once on a page. The use of landmarks will be very important in mashups and other pages that are generating dynamically from many sources. So there will not be one author who will manage the entire we page.

Regions are also containers, so there could be NVDA commands to allow the users to read only the content contained in the region. This cannot happen with simple headers since headers are not containers.

I hope you will reconsider your implementation of this feature. I promote NVDA a lot in my courses and presentations on web accessibility. This feature would be very useful to help authors test their use of landmark roles and labeling to make their web resources more accessible. The options described hear will make it much easier for legacy applications to become more accessible.

I would like to know how I can help to make this feature available.

References: aria-label: http://www.w3.org/TR/wai-aria/states_and_properties#aria-label

ARIA Region: http://www.w3.org/TR/wai-aria/roles#region

[nvaccessAuto]

Comment 23 by jteh (in reply to comment 22) on 2010-11-13 06:36 Replying to jongund:

In the example above I would expect the screen reader to just render the text content "Complementary Weather". No information about the H1 would need to be rendered.

I already explained why this isn't an option for NVDA; see comment:9. NVDA doesn't render landmarks on separate lines, nor should we because they're not actually part of the text. We read the first line of text when quick navigation is used. Also, if the user is moving through the document with the cursor, they will definitely hear the redundant information, even if we did render landmarks on their own line.

There is also just the generic landmark of role="region", which would need a label for people to describe it.

Weather

Again, the landmark should only be used to communicate structure, not content. The whole point of headings is to communicate section names.

There's clearly a difference of opinion here and arguing about it appears to be pointless. I believe this is going to create redundancy and excess verbosity for our users, hence my position as outlined in comment:11.

[nvaccessAuto]

Comment 24 by dfarough on 2013-05-06 20:03 Could you please add support for AREA-label for Application roles?

[nvaccessAuto]

Comment 25 by dfarough on 2013-05-07 16:14 Could you also add support for aria-labelledby as that is what WAI-ARIA specifically asks for the application role.

[nvaccessAuto]

Comment 27 by Birkirrg on 2014-02-08 18:59 I believe there is a strong case for the possibility to label certain ARIA landmarks. This particularly applies to aria-label attribute used to distinguish different navigation menus. Visually you frequently have global vs page specific menus, often visually clearly distinguished (such as global menu across the top, page specific menu to the left). One way of resolving issues arising from WCAG 1.3.3 where instruction on page tell user to select a certain element from the top or left menu of the page, is to be able to mark these menus explicitly as such using the aria-label.

I do not see the need to be able to mark things such as the main, contentinfo or banner roles with an ARIA label, but navigating by landmarks in screen readers is a lot more cumbersome with NVDA due to the lack of support for aria labelling. aria-labelling, like any web technique can be used or abused by content authors. I have seen sites with over 20 accesskey attributes or over 40 headings, making these navigational aides virtually useless. But I think if a content author is using aria-labelling, it usually means awareness, and one would certainly assume that the labelling technique is used in a manner which facilitates effective navigation. Another case for aria labels is, as previously mentioned, role="region". container elements with role="region" are often displayed or hidden as a result of AJAX calls initiated by user (account info, user info, room layout info, etc.) and being able to explicitly label the region revealed as a result of that user interaction further helps distinguish this info, and helps screen reader user quickly identify what area of the page was just revealed. Jaws and Voiceover announce aria-labelling of landmarks, the ARIA keyboard navigation add-on for Firefox does as well. I cannot vouch for Talkback at the moment, although I am pretty sure it announces aria-labelling of landmark regions.

With the advent of HTML5 and the more widespread use of landmarks, both provided by webpages and more used as a navigational aide by screen reader users, I think it would be very beneficial to NVDA users to ahve thi information announced, or at lesat have a setting where they can select to have this info announced. I think the incoonvenience of over verbose output is significantly outweighed by the more effective landmark navigation possibilities. Of course that is just one user opinion, albeit one with decades of screen reading experience, and ultimately the judgmment call lies with the developers who ahve done incredible magic with NVDA. I still hope that this issue will be reconsidered. Cheers. -B

[nvaccessAuto]

Comment 28 by jteh on 2014-02-18 03:26 Labelling for applications is being covered as part of #1354. Changes: Milestone changed from None to next

[nvaccessAuto]

Comment 29 by James Teh <jamie@... on 2014-02-18 03:29 In [b9dfbfae8e4d85622e47cbf324425be89cea617d]:

Merge branch 't1195' into next

Incubates #1195.

Changes: Added labels: incubating

[nvaccessAuto]

Comment 31 by jteh on 2014-02-20 06:37 Actually, this depends on some of the code for #1354 as well.

[nvaccessAuto]

Comment 32 by James Teh <jamie@... on 2014-02-20 06:52 In [db819f3a6f61d5edc6e62177ffc01e1d809bff6b]:

Merge branch 't1195' into next

Incubates #1195.

[nvaccessAuto]

Comment 33 by jteh on 2014-02-20 06:56 This doesn't work yet for IE because the name attribute isn't set on landmarks yet.

[nvaccessAuto]

Comment 34 by James Teh <jamie@... on 2014-03-03 06:51 In [f5c1aa750ec302a8ef3c064d3ba08ed8f7701ad0]:

Merge branch 't1195' into next

Incubates #1195.

[nvaccessAuto]

Comment 35 by James Teh <jamie@... on 2014-03-18 18:39 In [39bb571663c4a9104df6989f70fb35eb5e0e0aca]:

In browse mode, labels on landmarks are now reported. They are also included in the Elements List dialog.

Fixes #1195.

Changes: Removed labels: incubating State: closed

[nvaccessAuto]

Comment 36 by jteh on 2014-03-18 18:40 Changes: Milestone changed from next to 2014.2