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

In Firefox, NVDA causes the first link in the DOM to be skipped intermittently (the second link/focusable element is focused) #3575

Open
nvaccessAuto opened this issue Oct 11, 2013 · 11 comments

Comments

@nvaccessAuto
Copy link

Reported by schne324 on 2013-10-11 18:44
take the example code here:

<!DOCTYPE html>
<head>
    <title>NVDA Proof of Bug</title>
    <style type="text/css">
    :focus {
        outline: 2px solid #f00;
    }
    </style>
</head>
<body>
    <a href="#">First Link</a>
    <a href="#asdf">SECOND Link</a>
    <div id="asdf">asdf</div>
</body>
</html>

I am running the most recent update of Firefox and I am seeing the first link not receiving focus every time. This is a problem for pages with skip links as the first child of the body.

@nvaccessAuto
Copy link
Author

Comment 1 by mdcurran on 2013-10-13 22:28
Firstly, try turning off sayAll on page loads (NVDa menu -> preferences -> browse mode settings). This would be causing NVDa to read the entire page when it loads and therefore probably leaving focus on the final focusable node. Note that this is not really an issue for most users as they are well aware that focus will move because of the sayAll.
If the problem stil occurs with sayAll on page load disabled then I will look further into the issue.

@hidanielle
Copy link

I'm experiencing this issue currently and have tested without sayAll.

@hidanielle
Copy link

hidanielle commented Sep 7, 2016

This is a duplicate of #5230

I've tested this with SayAll enabled and disabled. With SayAll disbaled, NVDA will read out that you are focused on the first skip link and it is functional, but it does not receive visual focus. I believe this is still a bug, as without NVDA the buttons both receive visual focus. The button should receive visual focus in all cases.

@Adriani90
Copy link
Collaborator

@schne324, @hidanielle is this still an issue in last NVDA Alpha?
cc: @LeonarddeR

@Adriani90
Copy link
Collaborator

@Qchristensen we need your helpful eyes again. :-) Could you please test with NVDA last alpha or 2019.1.1 in different browsers if the first link gets visual focus, as it is claimed in this issue? Thanks.

@Qchristensen
Copy link
Member

In both Firefox and Chrome, what I found was:

  • If I refresh the page with F5, while the focus is on the second link, the page refreshes and the focus stays on the second link. Pressing TAB moves into the browser tab / menu area (as it usually does once you Tab past the last control on a page).
  • If NVDA is not running, when the page refreshes, neither link has focus and TAB takes focus to the first link.
  • If the focus is in the address bar and ENTER is pressed to load the page (as long as you haven't changed anything), the page loads, the focus stays in the address bar, and TAB moves to the first link.

One other thing I did find however, In Firefox, if the focus is in the address bar and you press F5 to refresh the current page, when you then press TAB, the focus moves through the firefox menu etc controls, and then jumps straight to the second link. I couldn't replicate that with Chrome, or with NVDA not running.

@erickbelfy
Copy link

erickbelfy commented May 30, 2019

With a given HTML code:

<div>
<nav>
<ul class="css-bnahpf">
   <li class="css-10tjp12">
       <button class="MuiButtonBase-root MuiButton-root css-1hk3q50 MuiButton-text" 
                      tabindex="0" 
                      type="button" 
                      aria-pressed="true"
          >
             <span class="MuiButton-label">
                     <span>Disable accessibility mode</span>
              </span>
              <span class="MuiTouchRipple-root"></span>
         </button>
    </li>
   <li class="css-10tjp12">
           <button 
               class="MuiButtonBase-root MuiButton-root css-1hk3q50 MuiButton-text" 
               tabindex="0" 
               type="button"
            >
                 <span class="MuiButton-label">
                         <span>Skip to document</span>
               </span>
               <span class="MuiTouchRipple-root"></span>
            </button>
      </li>
</ul>
</nav>
<header>
     <div>
         <div>
               <button class="hamburger-button" aria-label="main menu"> 
                     <span class="MuiButton-label"><svg ></svg></span>
                     <span class="MuiTouchRipple-root"></span>
              </button>
         </div>
    </div>
</header>
.....
</div>

With NVDA on, when i hit tab instead of going to the first nav->ul->li->button it goes to the header first button (hamburger-button), even with css turned off i can't reach the first button while NVDA on.

@Adriani90
Copy link
Collaborator

@jcsteh is this not the same behavior like in #4386? If yes, then I suggest to close #4386 in favor of this one because here we have more recent updates and code examples. What do you think?

@masi
Copy link

masi commented Jul 20, 2020

It's the setting "Enable browse mode on page load" that triggers the behaviour. In browse mode NVDA reads out the page title and the "first line" (?), which happens to be the link. A tab will focus the link and bring it into via via CSS, but NVDA does not repeat the text.
When I disable browse mode on page load NVDA will read out the page title and stop.

It doesn't seem to matter whether the first link is actually hidden or not. The point is that during the time NVDA reads out the beginning of the document the link will not get the :focus applied. You can test this with using :focus only with visual variations like colour changes, but without CSS that hides the content.

@fatimaazizz
Copy link

Have same issue as mentioned above css focus is visible on tab but NVDA remains silent .than tab to next 2nd element.
came back to element with shift + tab than NVDA reads it. this working fine chromevox.

@Adriani90
Copy link
Collaborator

@michaelDCurran does PR #14611 maybe also affect this positively?

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

8 participants