Open Bug 422981 Opened 15 years ago Updated 3 years ago
[a11y] better/different handling needed for onfocus blur
351 bytes, text/html
2.93 KB, patch
|Details | Diff | Splinter Review|
Bug 422981 if the focused element is clear after focusing an element, still update the caret position. Additional fix when shift-tabbing from a caret position inside a focusable element to skip over that outer element r=smaug
47 bytes, text/x-phabricator-request
|Details | Review|
Steps to reproduce: 1. View the attached test case. 2. Use Tab to move focus from link to link Expected results: You'd be able to use Tab to move focus to all of the links. Actual results: You are not able to use Tab to move past the fourth link; focus cycles back to the top of the page. Comments: I realize that *technically* this is not a FF bug: People (united.com for example) apparently have some reason for wanting to remove focus from an object which was just given focus, and FF is certainly doing that. :-) However, it poses a very serious accessibility problem for users with visual impairments using the keyboard to navigate among focusable objects. If it were just united.com where this behavior was present, the logical thing to do would be to bother them about the inaccessibility of their site. Unfortunately, a bit of searching found plenty of other sites using this technique. Therefore, I'm wondering if the behavior that results from an onfocus blur could be modified within Firefox. I discussed this issue with Marco and he had an interesting idea, namely rather than giving focus back to the document frame, give focus to the next focusable object. That would, I think solve the problem. Thanks in advance for looking at this!
I just tested with IE, and it behaves the same as Firefox: The focus goes back to the top of the document.
Component: General → Disability Access
QA Contact: general → disability.access
IMHO, it's a bug of the web page. What if the script of the fourth link set focus to the first link. We can't guarantee every link is in focus cycle if the webpage plays a trick.
Ginn: sure it's an erratic behavior of the web page. The problem is: it's commonly found, and people can't just always report all bugs they see on all websites they have to go through (and reports most often end up in /dev/null). So a workaround would be very useful to just avoid the issue. Sure, the page can play horrible tricks, but that's not the question here: apparently a lot of webpages just want to prevent some items from getting the focus, and why not. Putting the focus on the web document in that case does not seem to me to be bringing any useful purpose, while focusing the next element instead really provides useful behavior for the most common case (tabbing from link to link).
That being said, tabbing through to the fourth link gets the document to be focused, but then from there, pressing shift-tab goes back to third link, so somehow firefox remembers we were on the fourth link, and the issue is only that pressing tab doesn't bring to the fifth link. Conversely, tabbing through from the end of the document with shift-tab brings an odd behavior: after reaching the fourth link, pressing shift-tab again goes back to the fifth link, and pressing tab brings to the sixth link (!). So something can probably be done about this.
Hello all, I can also the reproduce the issue on Windows too. @Marco: Why this bug is defined as Linux specific? Best regards, Alex.
Probably because Joanie filed it, and back then, Bugzilla just took the platform of the person filing the bug and preset fields with it. Yes, as I commented myself above, this is also happening on Windows, and other bugs we have on file describe similar issues. Jamie just had something similar on his plate I think.
Flags: needinfo?(mzehe) → needinfo?(jteh)
OS: Linux → All
Hardware: x86 → All
The issue I was dealing with was a bit different and related to how core accessibility fires focus events. That is, focus moved back to the document, but we weren't firing an event. This issue is more than just accessibility APIs. It's a fundamental change to focus handling for the entire browser. I also think this would end up requiring a DOM spec discussion because it fundamentally alters the behaviour of blur(). In addition, I have serious concerns about the proposed behaviour. In this case, moving focus to the next focusable element makes sense. But what if the author displayed a dialog and then did a blur() when the dialog disappears? In that case, focusing the next focusable element may not make sense at all, and may actually be worse than just focusing the document; it could be in a completely unrelated section of the page. Add tabindex="-1", aria-hidden and aria-owns into that mix and you have a recipe for counter-intuitive confusion. I'm leaning towards a won't fix on this unless someone can come up with a foolproof, intuitive propposal... and even then, this would probably be up to the DOM team, who would then probably need to discuss it at the spec level. Yes, it's unfortunate that this happens in the wild and it'd be great to work around it if we could, but not if the workaround comes at the cost of breaking other things.
In comment 4 (https://bugzilla.mozilla.org/show_bug.cgi?id=422981#c4), I was proposing not to focus the next element immediately as initially proposed in the report, but to remember which element is supposed to be focused, and when pressing tab again, to focus the next element. Just like firefox already comes back to the previous element by pressing shift-tab.
Fair enough; sorry, I didn't quite grasp that properly as an alternative. So, in short, you're suggesting that focus would still return to the document (which is consistent with current blur() behaviour), but the tab position would be remembered for both tab and shift+tab, instead of just shift+tab as it is now. That seems reasonable, since remembering it for one and not the other seems inconsistent at best. I'm not quite sure who to poke about this. Marco, any idea who we can ask? :)
(In reply to James Teh [:Jamie] from comment #9) > I'm not quite sure who to poke about this. Marco, any idea who we can ask? :) Neil, can you comment on the questions/proposal summarized in comment #9?
Flags: needinfo?(mzehe) → needinfo?(enndeakin)
This is a possible patch that ensures that the caret position is updated in the case where an element to be focused is blurred while it is focused. Also partially fixes a case uncovered by this where shift+tab doesn't move backwards at all when the caret is inside a focusable element. This isn't a perfect fix but I think this overall works better than the existing behaviour.
Assignee: nobody → enndeakin
I confirm that this fixes the issue, thanks!
So, can this patch be commited, or is there something else to be done?
Attachment #9121738 - Attachment description: Bug 422981, if the focused element is clear after focusing an element, still update the caret position. Additional fix when shift-tabbing from a caret position inside a focusable element to skip over that outer element r=smaug → Bug 422981 if the focused element is clear after focusing an element, still update the caret position. Additional fix when shift-tabbing from a caret position inside a focusable element to skip over that outer element r=smaug
You need to log in before you can comment on or make changes to this bug.