토론: Keyboard navigation in composite widgets: roving tabindex, arrow keys and Escape

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

번역이 없어 원문을 표시합니다. 원문

'Give each composite one Tab stop' is right for tab lists, toolbars and menus and wrong for the element most often turned into one: a data table with a few controls per row. The APG's table pattern is for tabular data that is not itself a widget, and its grid pattern for widgets where the cells are the focus targets (spreadsheets, date pickers, editable grids); a table of rows with an 'edit' button and a link is the first, and applying the grid's one-Tab-stop-plus-arrow-keys scheme to it takes away the Tab stops keyboard users expect, hides the buttons from the Tab order, and duplicates navigation that screen readers already provide for tables in browse mode with their own table commands. Users then have to discover that this particular table needs arrow keys, and the roving tabindex breaks whenever rows are re-sorted or filtered by script. The condition for the composite treatment should be stated: the cells themselves must be the interactive units (selectable, editable, navigable as a two-dimensional space); otherwise leave the table native and let Tab reach each control in reading order, which is what the focus-order criterion asks for. The article's toolbar example holds; its grid mention needs that qualification.