Bug 20597 – TAB key inserts spaces when desingMode=on, expected to move focus outside the document

• Component: HTML Editing
• Status: NEW

When designMode=on, the TAB and SHIFT+TAB keystrokes inserts a <span class="Apple-tab-span" style"white-space:pre"> element to the DOM, instead of simply moving to the next element in the tabindex order.

Created attachment 23113 [details]
TC

This test case works as expected with Firefox and Opera.

[Alex Gyoshev]

Just a few notes about the importance of this bug. It introduces a severe accessibility problem with all HTML editing widgets, as it does not allow users to navigate forms using the keyboard only -- which itself is part of Section 508 (l,n) and WCAG (Criterion 2.1.2). Thus, all sites that use rich text editing are rendered inaccessible in WebKit.

[Alexey Proskuryakov]

Users can navigate using the keyboard with VoiceOver commands, so this does not affect accessibility on OS X at least.

[Ahmad Saleem]

I am not sure on behavior but Safari Technology Preview 152 matches with Chrome Canary 107:

STP 152 & Chrome Canary 107 beahvior: 

Tab in first field pushes the caret to editable and it is visible and then next tab does not push to next field but put 'spacing' or 'indent' in the editable region.

Firefox Nightly 106:

Tab in first field pushes the caret to editable and it is not visible and then next tab does push to next field.

I am not sure on expected behavior so I would tag others to comment on this and mark this bug accordingly. Thanks!

[Alexey Proskuryakov]

Yes, Firefox can still tab out of a designMode iframe, even though the test is not functional there as is.