9

We are implementing accessibility on our existing web applications. We work with Firefox and NVDA. Little introduction on our web applications : Our web applications are forms with multiple steps (step 1, step 2 : those are different web pages). Each step have a previous / next hyperlink to go to the previous or the next step. At the final step, users see their inputs and can submit the forms or go back to change values. When user go to a previous page to change some values, we put an #anchor so the page go to that anchor. Then, in Jquery, I put the focus on the first focusable element after that anchor.

This works great except when NVDA is active :

When NVDA is active, NVDA force the focus on the HTML element that was last used when user was on this page the last time. In my case, NVDA put the focus on the Next hyperlink. NVDA overrides my focus I've set in my $(document).ready() function.

I've tried to change almost all settings in NVDA but haven't found one that fix my problem.

I've search the web for any ARIA attribute I could set to tell NVDA I'll manage focus and navigation but I haven't found anything there.

Anyone know how to resolve this issue?

Thanks a lot!

Mathieu G
  • 405
  • 5
  • 18
  • I don't follow the "we put an #anchor so the page go to that anchor". Do you mean you can edit your name and it jumps back to that control, or do you mean the prev button sets focus on just inside the form, so people don't need to navigate through the rest of the page? – Ryan B Mar 21 '14 at 17:13
  • We put an anchor on top of a section. At last step, user can decide to modify their input of one section so they click on the modify button, we bring it back to that steps and the anchor position it to that section of the step. Example : In step 1, you fill info about you, your spouse and your childs. At the final step, you want to change your spouse birthday. So you click on modify next to spouse info, the application bring you back at step 1 and an anchor position you to the spouse section. Don't know if i'm clear enough. Would really like to be able to post an example. – Mathieu G Mar 21 '14 at 19:15
  • You can edit your post and post code. Just puost a snippet or something. – Ryan B Mar 24 '14 at 12:42

3 Answers3

2

I know this is a few months old, but I've just run into the same problem and after a long night of banging my head against the desk, I asked on the NVDA bug tracker and it turns out that this strange behaviour is actually by design(!)

Anyway, I found a fix that works for me, anyway, with Firefox 32 and NVDA 2014.2

$(document).ready(function() {
        function resetTab(){
            document.getElementById('toplink').focus();
        }
        window.setTimeout(resetTab, 250);
    });

Needs jQuery or another method of detecting a loaded window. And obviously needs an element with the id of "toplink" too, or change the ID in the code. Let me know if this works for you :)

digitaltoast
  • 659
  • 7
  • 23
1

As reported by digitaltoast the behavior is by design, see Focus cached on form submission #5351

Directly, the focus is not being cached. We're caching the user's last position on the page, which indirectly causes the focus to be changed. Caching the user's last postion is necessary to ensure that navigating back and forward between pages, restoring a closed tab/window, etc. puts the user in the right position, which is a feature our users require and expect. Unfortunately, it does have the side effect you describe.

The issue does not appear if the URL changes, so a possible solution could be to add a random parameter to the query string

A GET form seems to be not affected (URL changes) until is submitted with same data (URL is the same), then issue shows up.

I noticed also that the issue is not present if the form is in an IFRAME

Testo Testini
  • 2,200
  • 18
  • 29
0

In my case, NVDA put the focus on the Next hyperlink. NVDA overrides my focus I've set in my $(document).ready() function.

This sounds like if a person clicks on previous, you are doing

<a href="#" onClick="history.go(-1); return false;">Go back</a> 

Which I think it might be a browser-related issue. Some remember where you were after you leave a page. Since you are not reloading the page, just going back, ready() is not firing again. The question of making ready() fire again, was already asked, which may be some some help. But you may have some issues determining if the user pressed back, given my assumption.

I've search the web for any ARIA attribute I could set to tell NVDA I'll manage focus and navigation but I haven't found anything there.

ARIA will do nothing here. The issue is how you are navigating backwards in your application.

The only way I can fix this is to re-engineer the application. If you are relying on history.go(-1), you will need to make a new function that mimics ready().

Community
  • 1
  • 1
Ryan B
  • 3,364
  • 21
  • 35
  • I'm not doing history.go(-1). It's an asp.net application and each action are doing postback. We are doing server side validation only (... i know ;) government stuff, old architecture). So the document.ready() function is firing! – Mathieu G Mar 21 '14 at 19:18