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

Blurring an application reads the previous anchor #5292

Closed
nvaccessAuto opened this issue Aug 18, 2015 · 10 comments
Closed

Blurring an application reads the previous anchor #5292

nvaccessAuto opened this issue Aug 18, 2015 · 10 comments

Comments

@nvaccessAuto
Copy link

nvaccessAuto commented Aug 18, 2015

Reported by Bogdana on 2015-08-18 05:14
Hi guys,

While developing an accessibility compliant site for one of our biggest clients, we faced an issue which I believe is a bug of NVDA. I will give you a short example:

<a href="#">Link 1</a>
<div role="application">
<a href="#">Link 2</a>
</div>
<a href="#">Link 3</a>

If the focus is on Link 1, then you press tab, NVDA reads “application link 2”, which is fine. The issue is when you press tab again – the focus is being placed on Link 3, but NVDA announces “Link 1 Link3”. Link 1 is being announced despite of the fact that it has not been focused. The event when this occurs is blur – i.e. when you blur outside of an application, NVDA reads the first previous anchor, and I cannot get the logic here.

Any thoughts on the matter will be appreciated.

@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2015-08-18 23:46
Hmm. Interesting.

What is happening here is as follows:

  1. When you tab to link 3, focus is returning to the document.
  2. Whenever focus returns to a document that is in browse mode, NVDA reads the line where the cursor is located, which in this case is the line containing "link 1".
  3. NVDA then moves the cursor because the focus hit "link 3" and then reports it accordingly.

The question is how we can skip step 2 in this case without breaking other focus use cases.

@nvaccessAuto
Copy link
Author

Comment 2 by jteh on 2015-08-18 23:53
There's actually another (perhaps more common) way to reproduce this:

  1. Go to http://www.google.com/ with Firefox.
  2. Switch to browse mode and move to the Gmail link near the top of the page.
  3. Press f6 to move to the location bar.
  4. Press shift+tab until you hit the document.
  • Expected: "Google document, About link"
  • Actual: "Google document, link Gmail, About link"

@nvaccessAuto
Copy link
Author

Comment 3 by Bogdana (in reply to comment 2) on 2015-08-19 06:32
Replying to jteh:

There's actually another (perhaps more common) way to reproduce this:

  1. Go to http://www.google.com/ with Firefox.
  2. Switch to browse mode and move to the Gmail link near the top of the page.
  3. Press f6 to move to the location bar.
  4. Press shift+tab until you hit the document.
  • Expected: "Google document, About link"
  • Actual: "Google document, link Gmail, About link"

Thanks for replying!

I think we are in a different situation than the one described above.

Please review the example here: http://fiddle.jshell.net/u40gx5kk/2/show/
Navigate through the links using tab. When you tab-out of "Link within application", NVDA will first say "Link right before application" and then "Link outside application".

'''Expected:''' NVDA should only read "Link outside application" when you tab-out of "Link within application".

Regards,

@nvaccessAuto
Copy link
Author

Comment 4 by jteh on 2015-08-19 06:52
It is the same situation. Tabbing out of an application is just like coming back into the document, since the application is treated as being outside the document.

@nvaccessAuto
Copy link
Author

Comment 5 by Bogdana (in reply to comment 4) on 2015-08-19 07:05
Replying to jteh:

It is the same situation. Tabbing out of an application is just like coming back into the document, since the application is treated as being outside the document.

I see.. Thanks !

@LeonarddeR
Copy link
Collaborator

Confirmed that this issue still occurs with NVDA 2017.4

@Adriani90
Copy link
Collaborator

cc: @mltony

@Adriani90
Copy link
Collaborator

This issue is still occuring in NVDA 2018.4.1

@scottaohara
Copy link

Was about to file an issue for this but GitHub's autocomplete results made me aware of this one instead :)

Just for an additional test case: https://codepen.io/scottohara/pen/vPXKMd

@Adriani90
Copy link
Collaborator

Closing as duplicate of #6687 which is newer and contains a bit more technical info.

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

No branches or pull requests

4 participants