Community
Participate
Working Groups
Build Identifier: 0.3 The link to login is currently the last in the tab order. This means that a non-logged-in user who is using a screen reader must tab through the entire first page to even realize that authentication is required. Since this is the first action a keyboard-only user must do, it would make sense to have the popup/link as first in the tab order. Browser: Firefox 9 (though it should happen on any browser) Reproducible: Always
I am not sure, but it might be possible to keep the "Sign in" link where it is, and add tabindex="1" to the link tag, something like: <a href="http://etc" tabindex="1">Sign in</a> However, please consider that perhaps having the authentication controls way over on the right is not the optimal place, even for general usability. When the user is not yet signed in, should authentication be the most important thing? Or perhaps the typical "click-through" type of login makes sense? i.e. when the user clicks on something that requires authentication, present them with a login page, then after they login, take them to the page they originally requested. For example, this Bugzilla does that if a non-logged-in user wants to create a bug. The first sentence of the click-through page is "I need a legitimate login and password to continue." followed by the login/password input controls. Only then do you get to create your bug.
Susan has been rearranging the header including the "Sign In/Out" actions. This bug seems to be related to bug 367784.
yes, let's see where we end up when the dust settles. I'll mark 0.4 so we don't forget.
The basic problem here is that multiple divs with float right show the items backwards. I corrected this by inserting them in reverse order. This causes the tab order problem. I think we should live with this for 0.4 because it's not a simple/low risk solution. I couldn't get a higher tabindex to work at all, and after reading up on tabindex, I'm reticent to introduce numbers where there were not before, because an assigned tabindex gets priority over no tabindex which is not necessarily what we would want. In looking at what the rest of the world does, the recommended solution is typically to nest everything you want floated right into one float right div, rather than float each element right. Problem is that doing so causes layout problems for us that we'd have to fix. We were using the multiple float right to get a horizontal layout, removing it stacks up the right hand side. Another solution used is to use css negative margins to reposition things relatively. Yuck, that sounds like big trouble. The thing we should do here is just like in bug 371136. We should wrap everything that needs to be floated right in a <ul><li>....</ul>. In doing this we can then float the whole list right and set the individual elements to float left, controlling layout with the CSS on the whole list. Then things can be added in the expected order, still float right, etc. and all the extra layout goodness discussed in bug 371136. Come to think of it, we would have had to have done this anyway when doing bug 371136 because part of that bug will be to take off individual element margins, and then those who aren't in the command framework will need to do their layout similarly. http://doctype.com/float-right-li-without-elements-being-backwards http://www.dynamicdrive.com/forums/showthread.php?t=28936 http://stackoverflow.com/questions/6173589/how-to-float-elements-right-and-still-keep-tabindex
fixed. similarly to bug 371136, the main thing was separating some of the layout in our styles from other common info. That made it simpler to change the composition/nesting of the header. Fixed a few layout glitches with menus while I was here.
