Entering and exiting landmarks

[lgreco-ucb]

Steps to reproduce:

Create a page with with complementary landmark in the middle of a block of text, with a small amount of text within that landmark. Read the extended block of text with NVDA, attempting to identify the beginning and the end of the landmark.

Actual behavior:

NVDA does identify the beginning of the landmark, but does not the identify when the landmark as ended. Users need to know when the landmark itself has ended, so that they can identify continuing text vs. complementary text.

Expected behavior:

NVDA says "complementary region" when entering the landmark, and "end of complementary" when moving back into the standard block of text.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2019 .2.1 release

Windows version:

10.0.18362 Build 1836.2

Name and version of other software in use when reproducing the issue:

Firefox 69.0.3

Other information about your system:

Windows Surface 2

Other questions

Does the issue still occur after restarting your PC?

Yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

No

[LeonarddeR]

I think this behavior is on purpose. However, I agree that it might make sense to change it, or may be for some. I don't care when I leave the banner landmark, actually, but leaving the main or complementary landmarks is certainly good to know.

[lgreco-ucb]

we have been telling authors that they should be using complementary as a way to add foot notes but if the screen reader user can't tell when the foot note ends and the text starts up again this will not work so please consitor changing the behavuer to notify when leaving at least main and complementary Lucia Greco Web Accessibility Evangelist IST - Architecture, Platforms, and Integration University of California, Berkeley (510) 289-6008 skype: lucia1-greco http://webaccess.berkeley.edu Follow me on twitter @accessaces

…

On Fri, Oct 25, 2019 at 2:15 AM Leonard de Ruijter ***@***.***> wrote: I think this behavior is on purpose. However, I agree that it might make sense to change it, or may be for some. I don't care when I leave the banner landmark, actually, but leaving the main or complementary landmarks is certainly good to know. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#10420?email_source=notifications&email_token=ANSVYS4ZIXJ32GXK3DVWCXDQQK2LXA5CNFSM4JEXF3X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECHXXOI#issuecomment-546274233>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANSVYS7R2Z2KLORP32Q2MJLQQK2LXANCNFSM4JEXF3XQ> .

[LeonarddeR]

I'm about to file a new pr that fixes some small issues introduced by the most recent landmark redesign pr. @bramd, @jcsteh, @MarcoZeh @josephsl could you please share your thoughts about this?

[LeonarddeR]

we have been telling authors that they should be using complementary as a way to add foot notes ...

I think the note role is more sufficient for this. However, while there is an IA2 mapping, notes aren't read in browse mode. This should be changed I think.

[jcsteh]

The reason we originally didn't report leaving landmarks is that it causes excessive verbosity for consecutive landmarks. For example, if you have a navigation landmark immediately followed by a main landmark and you press down arrow to move out of the navigation landmark, you're going to hear "out of navigation landmark main landmark". Vice versa if you move up out of the main landmark into navigation. That's going to get pretty annoying pretty fast.

That said, I can see this might be useful for some landmarks (like main).

Note that the ARIA spec says that complementary should be a top level landmark. That means you're going to end up hearing about leaving some other landmark when entering a complementary landmark.

I tend to agree that footnotes are better served by the note role and that we should read both entry and exit for that.

[lgreco-ucb]

I think it's actually fine that the person find out that they are leaving the main to go to the footnote content then going back into the main when the footnote is finished a person really does need to know that they're going into that content and out of it again maybe there's something we can do with sound effects i.e said it so that it can make it click as it's going in or out of the landmark if we don't want it to be too for both what do you think

…

On Tue, Oct 29, 2019, 6:43 PM James Teh ***@***.***> wrote: The reason we originally didn't report leaving landmarks is that it causes excessive verbosity for consecutive landmarks. For example, if you have a navigation landmark immediately followed by a main landmark and you press down arrow to move out of the navigation landmark, you're going to hear "out of navigation landmark main landmark". Vice versa if you move up out of the main landmark into navigation. That's going to get pretty annoying pretty fast. That said, I can see this might be useful for some landmarks (like main). Note that the ARIA spec says that complementary should be a top level landmark. That means you're going to end up hearing about leaving some other landmark when entering a complementary landmark. I tend to agree that footnotes are better served by the note role and that we should read both entry and exit for that. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#10420?email_source=notifications&email_token=ANSVYS47PL5TSHWWUUDFA7LQRDRERA5CNFSM4JEXF3X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECSUNMA#issuecomment-547702448>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANSVYS5TFMQ5Z6WWT752L43QRDRERANCNFSM4JEXF3XQ> .

[MarcoZehe]

So, if complementary is a top level landmark, like main, nesting complementary within main is actually not a valid use case. In that case, having that extra verbosity would be superfluous, would it not? Therefore, I'd vote for changing the advocacy to treat footnotes with role "note" and to expose those via NVDA with entering and exiting statements, like lists, for example.

[JulienCochuyt]

@LeonarddeR wrote:

I don't care when I leave the banner landmark

I agree, but only when it is immediately followed by another one.
If not, I'm still interested in knowing where it ends.

Proposal: Announce when leaving landmarks only when not entering a new one.
Verbosity would not be increased in case of consecutive landmarks, but the user would still know what is being read.

[LeonarddeR]

Proposal: Announce when leaving landmarks only when not entering a new one.
Verbosity would not be increased in case of consecutive landmarks, but the user would still know what is being read.

I've thought about something among these lines. I'd imagine this should also apply to cases of the announcement of out of list list with 1 item out of list list with 1 item out of list irritation, haha.

Example:

data:text/html, <header>this is a banner<?header><main>This is the main content</main>

Rather than not announcing leaving the banner landmark, I propose an announcement like: from banner to main landmark.

For:

data:text/html, <ul><li>First entry></li></ul><ol><li>second entry</li></ol>

Instead of out of list, list with 1 item, something like: new list with 1 item, next list with 1 item. I can't come up wit hthings that really fit both landmarks and lists.

[JulienCochuyt]

@LeonarddeR wrote:

I'd imagine this should also apply to cases of the announcement of out of list list with 1 item out of list list with 1 item out of list irritation, haha.

Very good point. This is really annoying.

Example:

data:text/html, <header>this is a banner<?header><main>This is the main content</main>

Rather than not announcing leaving the banner landmark, I propose an announcement like: from banner to main landmark.

I'd rather stick with the idea of not announcing the leave when entering a new one.
We often receive quite a lot of criticism towards too verbose announcements.
For nested regions, we could disambiguate with something like "nested region blah", leaving the extra verbosity for the seldom nested cases and shorter announcements for the more common side-by-side ones.

For:

data:text/html, <ul><li>First entry></li></ul><ol><li>second entry</li></ol>

Instead of out of list, list with 1 item, something like: new list with 1 item, next list with 1 item. I can't come up wit hthings that really fit both landmarks and lists.

I fully approve.

EDIT:
Do you mean "new" and "next" as alternative wording proposals, or to announce "new" when entering the first one and "next" when entering the second one?
If the former, I think "next" is more explicit as "new" might lead to confusion whether the lists are nested or not.
If the latter, I think we could omit the word "new" which does not add much IMHO. (It translates to the longer "nouvelle" in French, which adds to the length of the announcement without real benefit)

[LeonarddeR]

Based on what @JulienCochuyt wrote, here's another idea:

1. For landmark to landmark and list to list, only announce the new landmark or list
2. For nested landmark and nested lists, add the word nested to entry. For lists, don't add the word nested for exit.

As an alternative to 2, we should be able to find out the level of nesting, as TextInfo.getTextWithFields retrieves all the fields from the root node up to the most inner one. So, getting fields for a landmark in a landmark should retrieve fields for both landmarks, and than we should be able to report level 2 for the inner landmark. This means that the nested announcements can also be suppressed when people want to disable position info. This would also be a fix for #8103.

[accessaces]

ok so i can tell my devs to chage the footnotes to role of note. but when can i then expect it to work in NVDA as Leonard says it does not work in brows mode. lucia Greco the course we are working on will go live in the spring and expects several 1000 students. so i need to give them a recommendation that will work thanks http://accessaces.com follow me on twitter @accessaces

…

On Wed, Oct 30, 2019 at 3:22 AM Leonard de Ruijter ***@***.***> wrote: Based on what @JulienCochuyt <https://github.com/JulienCochuyt> wrote, here's another idea: 1. For landmark to landmark and list to list, only announce the new landmark or list 2. For nested landmark and nested lists, add the word nested to entry. For lists, don't add the word nested for exit. As an alternative to 2, we should be able to find out the level of nesting, as TextInfo.getTextWithFields retrieves all the fields from the root node up to the most inner one. So, getting fields for a landmark in a landmark should retrieve fields for both landmarks, and than we should be able to report level 2 for the inner landmark. This means that the nested announcements can also be suppressed when people want to disable position info. This would also be a fix for #8103 <#8103>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10420?email_source=notifications&email_token=AHDG5Q5QARGCRFD4GIGA3S3QRFN7RA5CNFSM4JEXF3X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECTUFTY#issuecomment-547832527>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHDG5Q3P5PVDNIHWKWADRZDQRFN7RANCNFSM4JEXF3XQ> .

[JulienCochuyt]

@LeonarddeR,
The nesting level is indeed important for lists.
I do not think it is that much relevant for landmarks, though.
If a user wants a clear view of the page landmark structure, it is better served with the Elements List dialog presenting it as a tree focused on the current position.
I really appreciate the will to have identical behaviors as much as possible, but I'm not sure this is the best practical solution.

We've held a brainstorming on this subject here at Accessolutions and here is our proposal:

• When entering a landmark, announce it, but do not announce its ancestors landmarks if it is nested.
• When entering a list from an element that is not a list item, announce it with its nesting level if nested ("list level n, m elements, ...")
• When entering a list from an element that is a list item, announce it as above but omit the word "list", as currently done for trees.
• When leaving a landmark or a list, announce it only if the destination of the move is not a similar element.

The described behavior would apply for any kind of moves, be it from far away through quick- or nav- tab.
The main goal is to limit verbosity to the most useful piece.
Lengthier announces are by nature harder to understand, and counter productive if the most relevant part comes at the end.

As already mentioned on other threads, we plan to come up with a complementary command answering the question "Where am I?"
That way, common moves verbosity would not be increased but still a very complete information would be available at will, including lists, landmarks, selected tab, and headers.
I'll try to summarize this later proposal in a dedicated thread pretty soon.

What do you think?

[LeonarddeR]

* When entering a landmark, announce it, but do not announce its ancestors landmarks if it is nested.

What do you mean with "do not announce its ancestors landmarks"? Could you give an example here?

* When entering a list from an element that is not a list item, announce it with its nesting level if nested ("list level n, m elements, ...")

Agreed, though I propose ommitting level 1.

* When entering a list from an element that is a list item, announce it as above but omit the word "list", as currently done for trees.

That makes sense.

* When leaving a landmark or a list, announce it only if the destination of the move is not a similar element.

Agreed, though I don't see how this makes it possible to distinguish leaving top level landmarks from nested ones.

[JulienCochuyt]

* When entering a landmark, announce it, but do not announce its ancestors landmarks if it is nested.

What do you mean with "do not announce its ancestors landmarks"? Could you give an example here?

Consider a link C in a landmark B in a landmark A.
When jumping from outside A onto C, do not announce "landmark A, landmark B, link C" but rather "landmark B, link C" in order to reduce verbosity in case of nesting.
I'va already had to develop a custom WebModule for an application with so much nesting levels that it became practically unusable do to NVDA being over-verbose.

* When entering a list from an element that is not a list item, announce it with its nesting level if nested ("list level n, m elements, ...")

Agreed, though I propose ommitting level 1.

Indeed.

* When leaving a landmark or a list, announce it only if the destination of the move is not a similar element.

Agreed, though I don't see how this makes it possible to distinguish leaving top level landmarks from nested ones.

It does not. But we do not believe the extra verbosity is worth the benefit of the information, especially when there are other means to gain this information when in doubt (currently only through Elements List dialog)
Btw. this is the current behavior and I don't recall we ever received a complaint about it.

[Neurrone]

I'm not sure if this might be a bit off topic for this discussion, but I think speech refactoring could enable the use of sounds to indicate e.g, list nesting levels similar to indentation reporting. The use of sounds could also be potentially expanded to other use cases, such as the reporting of entering or exiting a landmark. Wanted to bring this up in case it could affect how this is implemented.

[JulienCochuyt]

@Neurrone wrote:

I'm not sure if this might be a bit off topic for this discussion, but I think speech refactoring could enable the use of sounds to indicate e.g, list nesting levels similar to indentation reporting. The use of sounds could also be potentially expanded to other use cases, such as the reporting of entering or exiting a landmark. Wanted to bring this up in case it could affect how this is implemented.

I like the idea of sound signals as they allow to drastically reduce verbosity.
However, unlike the switch between browse and focus modes, I think that this should be a setting disabled by default, in order not to confuse beginners.