Opened 7 years ago

Closed 7 years ago

#16103 closed defect (fixed)

BorderContainer: tab order of region="bottom" is incorrect

Reported by: Ben Gold Owned by: bill
Priority: undecided Milestone: 1.9
Component: Dijit Version: 1.8.0
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

When a BorderContainer contains a ContentPane or BorderContainer with region="bottom" and splitter="true", the splitter between the center container and the bottom container gets created in the HTML after the bottom container. The consequence of this is that the tab order becomes awkward: the user tabs through the content of the center pane, then tabs through the content of the bottom pane, then gets to the splitter. If nothing else this is then inconsistent with the region="top" splitter, since that order would be: tab through top pane, tab into splitter, tab into center content pane.

A sample for this is completely straightforward, just declare a BorderContainer with two content panes, one with region="center" and one with region="bottom and splitter="true".

This was originally found in our code on Dojo 1.5 but is reproduce in Dojo 1.8.

Change History (6)

comment:1 Changed 7 years ago by bill

Description: modified (diff)
Owner: changed from bill to Ben Gold
Status: newpending
Summary: BorderContainer:tab order of region="bottom" is incorrectBorderContainer: tab order of region="bottom" is incorrect

It sounds consistent to me; you always tab to the pane first, and then to the splitter. Why do you say it's inconsistent?

comment:2 Changed 7 years ago by Ben Gold

Status: pendingnew

It's not consistent in that the behavior changes depending on if it's region="top" or region="bottom. Here's the basic summary of the navigation/tab order depending on the state of the region flag:

region="top"

Top Border Container -> Splitter -> Center Border Container

region="bottom"

Center Border Container -> Bottom Border Container -> Splitter

Last edited 7 years ago by Ben Gold (previous) (diff)

comment:3 Changed 7 years ago by bill

Status: newpending

The behavior isn't changing, it always goes to the splitter after the pane. To repeat what you wrote:

Top Border Container -> Splitter

and

Bottom Border Container -> Splitter

Perhaps you are forgetting, or unhappy about, the fact that the behavior *is* consistent, rather than that the tabbing is in the visual order of the panes and splitters.

comment:4 Changed 7 years ago by Ben Gold

Status: pendingnew

Yes, the code is consistently putting the splitter after an edge borderContainer, but I don't think that's acceptable. The tab flow *should* follow the natural layout of the page, not arbitrarily jump because the implementation happens to make the bottom border container responsible for drawing the splitter.

According to IBM's internal guidelines for a11y compliance this component is failing because we are now required to make sure "focusable components receive focus in an order that preserves meaning and operability" (Web Accessibility Checklist Checkpoint 2.4E - WCAG 2.0). The tab order *must* now move roughly in the correct flow with the page.

At first glance, what you are arguing makes perfect sense from a coding/development perspective. The splitter always follows the component drawing the splitter. But in practice that order does not at all feel natural, particularly in our case where the UI in question uses all three regions (top, center, bottom) in a sidebar layout. The user ends up with the experience:

Enter top component -> navigate through top component's inner HTML -> splitter -> Enter middle component -> navigate through middle component's inner HTML -> Enter bottom component -> navigate through bottom component's inner HTML -> splitter

If you take away what widget object is responsible for drawing the HTML, the underlying semantic reason for this behavior, the navigation order makes no sense. If I was going to hard-code this layout, not using widgets, there's no way I would lay it out in this fashion.

My personal opinion would be for any pane in a borderContainer that is region=bottom, right, or trailing, and splitter=true, the splitter should be inserted in the HTML before the component itself. That would put the splitter into its natural position in the DOM and align it with its position in the visual layout (which is being manually manipulated with CSS).

comment:5 Changed 7 years ago by bill

Milestone: tbd1.9
Owner: changed from Ben Gold to bill
Status: newassigned

My personal opinion would be for any pane in a borderContainer that is region=bottom, right, or trailing, and splitter=true, the splitter should be inserted in the HTML before the component itself. That would put the splitter into its natural position in the DOM and align it with its position in the visual layout

OK, I guess that's reasonable (except in RTL mode it would be region=bottom, left, or trailing). I will change the behavior like that.

comment:6 Changed 7 years ago by bill

Resolution: fixed
Status: assignedclosed

In [29786]:

Make the tab order between panes and splitters match the visual layout: for any pane in a BorderContainer that is region=bottom, right, or trailing, and splitter=true, insert the splitter in the HTML before the pane, rather than after. Fixes #16103 !strict.

Note: See TracTickets for help on using tickets.