Skip to content
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

Entering and exiting landmarks #10420

Open
lgreco-ucb opened this issue Oct 24, 2019 · 18 comments
Open

Entering and exiting landmarks #10420

lgreco-ucb opened this issue Oct 24, 2019 · 18 comments

Comments

@lgreco-ucb
Copy link

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
Copy link
Collaborator

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
Copy link
Author

lgreco-ucb commented Oct 25, 2019 via email

@LeonarddeR
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Contributor

jcsteh commented Oct 30, 2019

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
Copy link
Author

lgreco-ucb commented Oct 30, 2019 via email

@MarcoZehe
Copy link
Contributor

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
Copy link
Collaborator

@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
Copy link
Collaborator

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
Copy link
Collaborator

JulienCochuyt commented Oct 30, 2019

@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
Copy link
Collaborator

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
Copy link

accessaces commented Oct 30, 2019 via email

@JulienCochuyt
Copy link
Collaborator

@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
Copy link
Collaborator

* 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
Copy link
Collaborator

JulienCochuyt commented Oct 30, 2019

* 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
Copy link

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
Copy link
Collaborator

JulienCochuyt commented Oct 31, 2019

@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.

@Adriani90
Copy link
Collaborator

I agree with @JulienCochuyt in #10420 (comment)
and have following remarks:

@JulienCochuyt wrote ancestors should not be reported when entering nested landmarks from outside in order to reduce verbosity:

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 think it makes sense to report "landmark b level 2 link c" because then the user knows that NVDA navigated into a nested landmark and this has a direct influence on container navigation with dot and shift+dot or comma and shift+comma.

@LeonarddeR wrote:

Agreed, though I propose ommitting level 1.

I think though level 1 is very important only in case of nested things. This makes it obvious that something is nested right when entering it.

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

I think in case of leaving nested landmarks NVDA could just report "leaving landmarks, and thus it is clear that multiple landmarks have been left. I agree for single landmarks without nesting there is no need to report when leaving them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants