Opened 11 years ago
Closed 11 years ago
#10039 closed defect (fixed)
Grid does not scroll horizontally when navigating column header cells with keyboard
Reported by: | Joseph Scheuhammer | Owned by: | Becky Gibson |
---|---|---|---|
Priority: | high | Milestone: | 1.4 |
Component: | DojoX Grid | Version: | 1.3.2 |
Keywords: | a11y, keyboard | Cc: | Joseph Scheuhammer |
Blocked By: | Blocking: |
Description (last modified by )
Testing: FF3.5 on Mac OS X Leopard with http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/grid/tests/test_keyboard.html (2009-10-05)
- Place focus on column header 1, (labelled "Column 1").
- Right-arrow to the next header cell in the row.
- Continue moving right until reaching the right edge of the view of the grid.
- The next move to the right still selects the next header in the row, but view does not scroll to the right.
- The result is that one cannot see the currently selected column header.
The above behaviour does not occur when navigating the data cells within the grid.
I suspect the reason it works for the data cells is that focus is put on them, and the browser scrolls them into view -- you get scrolling for free.
However, focus is not put on header cells. The system uses aria-activedescendent to track which header has virtual focus. It needs to scroll the view "by hand".
Note: sorting by key press on the currently "focussed" header does work, nonetheless.
Change History (5)
comment:1 Changed 11 years ago by
Description: | modified (diff) |
---|
comment:2 Changed 11 years ago by
Milestone: | tbd → 1.4 |
---|---|
Priority: | normal → high |
comment:3 Changed 11 years ago by
comment:4 Changed 11 years ago by
[20456] brings the behavior back to what it was before [20105] which had some edge cases. For example, give the test case above, with focus on the column 4 header, pressing the right arrow does not immediately scroll column 5 into full view. But pressing right arrow again will bring column 5 and 6 into view. Then even if you arrow back to column 1 then forward to column 5, column 5 will then immediately scroll into view as expected. Thus FocusManager?._scrollHeader() or _scrollInfo() probably needed additional tweaking. We can probably live with this in 1.4 since it is no worse that the existing 1.3.2 behavior.
comment:5 Changed 11 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Created #10064 to deal with remaining (minor) scrolling issue. Closing this as fixed since the behavior is now the same as it was in 1.3.2.
I'm fairly certain this is due to [20105] which refs #9756