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
ARIA Landmark Roles and Labeling the Landmark #1195
Comments
Comment 1 by kennpetri (in reply to comment description) on 2010-11-10 22:40
I'm writing to support this functionality. NVDA already supports landmark roles and having it voice the associated labels provides desired context. |
Comment 2 by jteh on 2010-11-10 22:47 |
Comment 3 by jongund on 2010-11-10 23:09 |
Comment 4 by rangin on 2010-11-11 16:04 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. 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. |
Comment 5 by mscott on 2010-11-11 16:57 |
Comment 6 by jteh (in reply to comment 4) on 2010-11-11 20:44
As a matter of interest, are you an NVDA user?
The label isn't structural information; the landmark itself provides the structure.
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.
Very possibly. However, this isn't predicated on landmarks having labels. |
Comment 7 by jteh (in reply to comment 5) on 2010-11-11 20:53
Right. However, placement alone can't tell you whether it is "News" or "Weather", for example. You determine this from context or headings.
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.
I agree that off-screen headings are hacky and shouldn't be used.
Here's a practical reason not to implement this feature:
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. |
Comment 8 by jongund on 2010-11-11 22:46 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 |
Comment 9 by jteh (in reply to comment 8) on 2010-11-11 22:56
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.
This is still incredibly redundant. I don't like hearing the same information twice, especially when it can be avoided. |
Comment 10 by johnfoliot on 2010-11-11 23:12 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. |
Comment 11 by jteh (in reply to comment 10) on 2010-11-11 23:18
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.
Personally, I'd argue that authors shouldn't bother using aria-label/aria-labelledby on landmarks. :)
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. |
Comment 12 by benjaminhawkeslewis (in reply to comment 11) on 2010-11-11 23:40
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! |
Comment 13 by johnfoliot (in reply to comment 12) on 2010-11-12 00:03
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. |
Comment 14 by jteh (in reply to comment 13) on 2010-11-12 01:57
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. |
Comment 15 by rangin on 2010-11-12 04:11
Yes, I use NVDA but not as my primary screen reader program mainly due to I have added recently NVDA to the list of screen reader programs that we |
Comment 16 by rangin on 2010-11-12 04:23
Other screen programs allow a great degree of customization. NVDA offers some level of customization but not nearly as other screen reader programs. |
Comment 17 by rangin on 2010-11-12 04:31
I hope you understand that the goal is here to make NVDA even a better and reliable screen reader. |
Comment 18 by jteh (in reply to comment 17) on 2010-11-12 05:22
Configurability isn't the correct solution here. The point is that there should not be redundant information in the first place. Replying to rangin:
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.
Not at present. Anyway, I've said my piece on this; see comment:11. |
Comment 19 by vtsaran on 2010-11-12 06:38 |
Comment 20 by benjaminhawkeslewis on 2010-11-12 06:43
If it's a lot easier for a sighted user to do this (i.e. with a glance), is that really an equivalent experience?
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).
Strictly speaking, I think ARIA does not impose any conformance requirements on consumers of accessibility APIs. |
Comment 21 by benjaminhawkeslewis (in reply to comment 18) on 2010-11-12 06:50
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? |
Comment 22 by jongund on 2010-11-12 15:12
or
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.
or
or
or
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 Region: |
Comment 23 by jteh (in reply to comment 22) on 2010-11-13 06:36
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.
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. |
Comment 24 by dfarough on 2013-05-06 20:03 |
Comment 25 by dfarough on 2013-05-07 16:14 |
Comment 27 by Birkirrg on 2014-02-08 18:59 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. 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. |
Comment 28 by jteh on 2014-02-18 03:26 |
Comment 29 by James Teh <jamie@... on 2014-02-18 03:29
Changes:
|
Comment 31 by jteh on 2014-02-20 06:37 |
Comment 32 by James Teh <jamie@... on 2014-02-20 06:52
|
Comment 33 by jteh on 2014-02-20 06:56 |
Comment 34 by James Teh <jamie@... on 2014-03-03 06:51
|
Comment 35 by James Teh <jamie@... on 2014-03-18 18:39
Changes:
|
Comment 36 by jteh on 2014-03-18 18:40 |
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
The text was updated successfully, but these errors were encountered: