Closed Bug 257938 Opened 20 years ago Closed 17 years ago

CSS scrollable areas should only be tabbable if they actually have scrollbars

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P5)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: kairo, Assigned: roc)

References

(Depends on 1 open bug)

Details

Attachments

(3 files, 1 obsolete file)

CSS scrollable overflow not focusable unless there are scrollbasrs
1.50 KB, patch
Details | Diff | Splinter Review
right-clicking now shows dotted border
83 bytes, text/html
Details
Aaron's patch, updated, v2
1.55 KB, patch
roc
: review+
roc
: superreview+
roc
: approval1.9+
Details | Diff | Splinter Review 
From #developers:

<KaiRo> aaronlev: hi... is it intended that webpage areas with overflow:auto and
no shown scrollbars (nothing to actually scroll) are getting a dotted focus
outline when clicked with the mouse?
<aaronlev> KaiRo, I couldn't code it perfectly to know when there was a scrollbar
<aaronlev> KaiRo, I suppose that part needs work
<aaronlev> KaiRo, I don't think it should get focus if there are no scrollbars

For an example of this behaviour, load http://home.kairo.at/ and click on the
main page area.
We discussed this. I think they should get focus.
Roc, forgive me for going senile. Remind me what our logic was?
It produces a more consistent tabbing setup. If tabbing depends on how tall the
overflow:auto element's content is, then tabbing ends up depending on things
like the current text size and possibly even what state DHTML is in.
Do we need to show a focus outline on the div even when we klick anywhere in the
div with the mouse?

I agree that it's good to show the focus ring when tabbing there by keyboard,
but it looks quite disturbing...
I think the use of overflow:auto on http://home.kairo.at/ is already quite
disturbing :-)

Are there other higher-profile sites where this is a problem?
> I think the use of overflow:auto on http://home.kairo.at/ is already quite
> disturbing :-)

Yeah, I can guess that ;-) Well, this is actually fallout from having a system
behind it should show a vertical scrollbar when the contents get too wide, and I
made up that personal page with the same system...

> Are there other higher-profile sites where this is a problem?

I don't know, I just thought we'd better think this out before it catches up on
us on any higher-profile sites (I only have a few lower-profile sites using such
techniques).
BTW, how do IE, Opera, Safari etc. handle that?
We have thought it out. We now need more feedback on what the impact is for
real-world sites.
I cross-checked one of my pages in Konqueror 3.3, IE 6, and Opera 7.51, and all
of them show no focus outline when I click the overflow:auto area of the page.
That's interesting but not really what I asked...

An alternative to focusing the overflow:auto element is to make keyboard
scrolling scroll the nearest scrolling element that contains the caret. This is
what I suggested originally but for some reason we decided that focusing the
scrolling element was better, I can't remember why.
(In reply to comment #9)
> That's interesting but not really what I asked...
Opera, Safari and IE fall down in their Section 508 compliance on this.

> 
> An alternative to focusing the overflow:auto element is to make keyboard
> scrolling scroll the nearest scrolling element that contains the caret. This is
> what I suggested originally but for some reason we decided that focusing the
> scrolling element was better, I can't remember why.
You have to be able to navigate to the item and scroll it, all without using the
mouse. The area where the keyboard is acting is called the focus. The focus must
always be visible.

I suggest that the tab order doesn't need to be consistent between viewing it on
different form factors. In my opinion we should fix it so the element should
only be focusable when scrollbars are visible. As a corollary the scroll bars
should only be visible when they're really necessary. Right now they seem to
appear at times that they shouldn't.

(In reply to comment #10)
> You have to be able to navigate to the item and scroll it, all without using
> the mouse. The area where the keyboard is acting is called the focus. The
> focus must always be visible.

But you could do that with caret browsing.

> I suggest that the tab order doesn't need to be consistent between viewing it
> on different form factors. In my opinion we should fix it so the element
> should only be focusable when scrollbars are visible. As a corollary the
> scroll bars should only be visible when they're really necessary. Right now
> they seem to appear at times that they shouldn't.

It's not just different form factors. It's also dynamic effects that change the
amount of content in a container, including incremental page loading.

I'm OK with switching to depending on scrollbar visibility and seeing how it goes.
(In reply to comment #11)
> (In reply to comment #10)
> > You have to be able to navigate to the item and scroll it, all without using
> > the mouse. The area where the keyboard is acting is called the focus. The
> > focus must always be visible.
> 
> But you could do that with caret browsing.
We could, but I don't want to rely on caret browsing for this. Caret browsing is
really a last resort. Normally a scrollable pane inside another document takes
focus. From the user's point of view it's no different from an iframe. They
don't know exactly what code is being used by the author to do it.

> It's not just different form factors. It's also dynamic effects that change the
> amount of content in a container, including incremental page loading.
Right, understood.

> 
> I'm OK with switching to depending on scrollbar visibility and seeing how it goes.
Okay. I think I had 2 problems doing that:
1) trouble reliably knowing when there was a scroll bar
2) scrollbars showing up when the information didn't really overflow the area

*** Bug 258228 has been marked as a duplicate of this bug. ***
> 1) trouble reliably knowing when there was a scroll bar

Did you file the bug about margins being included in GetActualScrollbarSizes? If
so I lost the bug number.

> 2) scrollbars showing up when the information didn't really overflow the area

That'd be reflow bugs which we'll just have to squash one by one.
No, the only spinoff bugs from bug 254966 so far are this one and bug 257672.
Depends on: 261040
Priority: -- → P3
This outline "breaks" the presentation of my own Web site:

http://www.dante.com/users/jasonb

Seeing the outline appear in the left of right hand pane (given the rest of my
content, it only shows as a dotted line at the top of either pane) makes it look
terrible.

Note that I'm using overflow:auto AND have scrollbars but the outline still
appears.  (Granted, I'm using nested DIVs.)  Is this a different bug that I
should file or is it actually covered here?
Jason, the outline is supposed to appear when you have scrollbars. Aaron insists
that elements with scrollbars should visibly take focus. The only possible
compromise would be to indicate focus in a way that's less annoying to you but
still visually consistent with other focusable elements. I don't see what that
could be.
What is really the benefit of showing the focus on an element with scrollbars
(overflow:auto)? For keyboard navigation I see the point, but not when scrolling
an element with the mouse. It doesnt look good.
> For keyboard navigation I see the point,

It's important to show what is focused *before* the user presses any keys, so
they can see what will be acted on if they do press a key. It'd be hard to know
in advance whether the user is going to use the keyboard :-)
(In reply to comment #18)
> It doesnt look good.
Probably because we should show the outline inside the border when we do it for
focus. Think of it similar to when an iframe gets focus. That's not considered
ugly. Maybe give it the right look by using outline-offset (need to implement it
first).


(In reply to comment #20)
> Think of it similar to when an iframe gets focus. That's not considered
> ugly. 

Difference is that when i click on the scrollarrows in a frame it doesnt focus
it, only when i TAB into it. Now elements with scrollbars gets focused just by
scrolling them.
> Aaron insists that elements with scrollbars should visibly take focus.

I don't understand why this should happen unless the element that's being
focused is an input element - something in which you'd type.

Plus, if the method by which you've selected something is by *clicking* on it
with your mouse, then it should be obvious that the keyboard is not being used
and there need be no visual indication of where you are - it's obvious since you
clicked there.

IMHO, only if the user has used the keybard (Tabbed) to get to an *input*
element should the outline be shown...

> the outline is supposed to appear when you have scrollbars

Okay, I've got that.  (I should have read the bug more carefully.)  But is it
also supposed to appear when there *aren't* scrollbars (because it does) - or is
that what this bug is debating specifically?  So far, the discussion seems to be
talking about outlining in general...
Well, it's not a high-profile site, but this site suffers quite heavy of this
bug/feature: http://turkeybot.info/
(it also triggers quite a lot of incremental reflow bugs in Mozilla, I think.
Click for example on the heading: "Welcome to Turkeybot")
Martijn:
Yes, we seems to have quite a few interesting reflow bugs as well, the community
site I'm working on as http://com.naddy.at/ suffers from this bug and some
interesting reflow issues as well.

We should try to narrow down simplified testcases of those, but I didn't manage
to do that for the reflow bugs I see there :(
(That's off-topic on this bug though, so I better shut up...)
Found a website that might be broken due to this, not sure, just guessing
though. Filed it as bug 262104.
> You have to be able to navigate to the item and scroll it, all without
> using the mouse. The area where the keyboard is acting is called the
> focus. The focus must always be visible.

I understand this with respect to focus when using keyboard navigation.  But I
still don't understand why we need an outline when clicking on something.  In
that case, I know exactly what has focus because I've explicitly selected it
with my mouse.  If this is off-topic for this bug, please respond to me offline
or let me know in which forum / other bug this is being / has been discussed.
This bug has, as it seems, majorly broken the user experience at
http://www.mysql.com. Clicking links within the navigation makes it jump up and
down erratically, forcing the user to have to click the "jumped link" once again
to be able to navigate through the site. It is sufficient to hold the tab button
on the keyboard pressed down to navigate between links to see how the page
elements jump around.
I don't know if the outlining is what's causing jumping links.  It doesn't sound
like an immediate correlation.  However, the more I surf, the more sites I see
that are "ruined" by this effect for me, and for no good reason (see my comment
26).  It's quickly becoming less a curiosity and more a major annoyance.
*** Bug 262565 has been marked as a duplicate of this bug. ***
Setting the pref browser.display.focus_ring_width to 0 seems to kill most
similar borders (e.g. around textlinks, images) but the border around
overflow:auto areas discussed here remains the same...
Thanks, Rob!  This is definitely useful.
I just filed bug 262577 to address the specific situation where div:overflow
elements do not honour the "browser.display.focus_ring_width" preference.  I
also filed bug 262578 to see if we can get elements outlined only when tabbing
into them - not when navigating to them via mouse actions.
Could bug 262401 be related to this bug?
Attachment #161097 - Flags: superreview?(roc)
If we fix bug 262578, we don't have to fix this. Right?
> If we fix bug 262578, we don't have to fix this. Right?

I believe that would be a fair assessment.  Unless there's anybody who clicks on
a DIV and still isn't aware of what they've clicked on?  I can't think of any
such circumstance, but don't want to rule it out blindly if somebody can think
of such an example...
Some people have the habit of selecting text while they read it; sometimes this
is even necesessary to get the text readable due to bad color selection by the
website developer.  So they would click on the div and get the outline.
(of course they also get the inverted text, disturbing the layout anyway)

IMHO the whole focus ring stuff should be made optional.  There is a user pref
(comment #30) for it, but I have found no UI for it.  And not all code obeys it yet.
Add some checkmark and/or focus-ring-width field somewhere in the preferences,
turn it off by default, and those who need it can enable it without annoying others.
To be honest, I still think we should fix this. It's just nicer to have only
keyboard actionable items in the tab order.
Depends on: 262577
Mozilla Windows Trunk Nightly Build Regression Window
Pass: 2004071609
Fail: 2004071808

I got to this bug as on my site I also use overflow:auto. More I use
border-right: dotted 1px; When I clicked in this element in M1.8a4 I got dotted
border around the whole element - I thought border is filled around whole
element, but here I see it is not border itself but it is a focus outline. Seems
fairly missleading to me. I do not think outline should be shown if focused with
mouse.
Adam, you should be more interested in bug 262578.  It's actually just waiting
final approval.
Attachment #161097 - Flags: superreview?(roc)
I believe that the just checked in bug 262578 also fixed this bug.  Going to
http://home.kairo.at/ I no longer see any focus outline when clicking on the
main frame.  (The focus outline only appears when tabbing into it which, AFAIK,
is what we want to happen.)
Most of the issue was taken care of by the checkin for bug 262578. However, this
bug wasn't really just about clicking -- it was really about whether focus
outlines should be shown on these elements at all.

Changing summary to reflect the current state of things: focus outlines only
show up on css scrollable items when the element is tabbed to. I don't think
they should be in the tab order at all. Roc disagrees.

I want to leave this bug open for feedback for now.
Severity: normal → minor
Priority: P3 → P5
Summary: overflow:auto areas without scrollbars show focus outline after being clicked → Should css scrollable areas without scrollbars be tabbable?
Target Milestone: --- → Future
*** Bug 311447 has been marked as a duplicate of this bug. ***
Simply right-clicking on the div with overflow:auto; is now showing the dotted
border, and it's real nice how it can mess up a layout if a user simply wants
to open up a context menu and do so clicking in a div with auto overflow.

Aaron Lev, is that patch attached still usable?
Flags: blocking1.8rc1?
(In reply to comment #45)

I do not see any troubles with seamonkey 1.0a.


(In reply to comment #45)
> Created an attachment (id=198767) [edit]
> Aaron Lev, is that patch attached still usable?

I'm on vacation until October 17.
Assignee: aaronleventhal → roc
Flags: blocking1.8rc1? → blocking1.8rc1-
I don't see this in Firefox trunk builds.
*** Bug 317372 has been marked as a duplicate of this bug. ***
Blocks: 296259
http://www.w3.org/TR/CSS2/visufx.html
auto
    ... but should cause a scrolling mechanism to be provided for OVERFLOWING boxes.


I have next form:
<form>
<div style="overflow: auto;">Label1</div><input>
<div style="overflow: auto;">Label2</div><input>
<div style="overflow: auto;">Label3</div><input>
</form>
DIV elements are not overflowed, so they should not provide scrolling mechanism, so they have no need to be accessible through keyboard, so they should not participate in tabordering and MUST NOT be FOCUSable unless overflowed (scroll bars are showed)

If I want elements be focused I can do next:
<form>
<div style="overflow: auto;">Label1</div><input>
<div tabindex=0 style="overflow: auto;">Label2</div><input>
<div style="overflow: auto;">LabelX</div><input>
</form>
so overflow: auto elements with no scrollbar still get tabbed to.  that's cool.  or is it lame?  i'll go with lame.

(In reply to comment #11)
> I'm OK with switching to depending on scrollbar visibility and seeing how it goes.

it sounds like everyone's on board with implementing aaron's patch.  why hasn't it landed?
Aaron didn't ask review for his patch.
Comment 43 says he wanted to wait for feedback on this.
I agree that overflow:auto elements with no scrollbar being tabbable doesn't seem useful.
Aaron, do you want to ask review on the patch? Or do you think current behavior is better?
Attached patch Aaron's patch, updated (obsolete) — — Splinter Review 

    
    

    
  
I'm okay with it either way, and I don't have time to deal with it right now. If someone else wants to drive this issue that is fine with me.

        Attachment #277502 -
        Flags: review?(roc)

    
    

    
  
+          nsMargin margin = scrollFrame->GetActualScrollbarSizes();
+          if (margin.bottom || margin.right) {

Should check margin.top and margin.left too; margin.left is certainly possible in RTL situations.

    
    

    
  
(In reply to comment #34)
> Created an attachment (id=161097) [details]
> CSS scrollable overflow not focusable unless there are scrollbasrs
> 

This would certainly solve some accessibility issues we're finding with Orca and our caret navigation.

    
    

    
  


  
Sorry for the delay.

        Attachment #277502 -
        Attachment is obsolete: true

        Attachment #278819 -
        Flags: review?(roc)

        Attachment #277502 -
        Flags: review?(roc)

        Attachment #278819 -
        Flags: superreview+

        Attachment #278819 -
        Flags: review?(roc)

        Attachment #278819 -
        Flags: review+

        Attachment #278819 -
        Flags: approval1.9+

    
    

    
  
Checking in nsFrame.cpp;
/cvsroot/mozilla/layout/generic/nsFrame.cpp,v  <--  nsFrame.cpp
new revision: 3.751; previous revision: 3.750
done

Checked into trunk.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED

    
  
Summary: Should css scrollable areas without scrollbars be tabbable? → CSS scrollable areas should only be tabbable if they actually have scrollbars
Component: Keyboard: Navigation → User events and focus handling

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: