• Success Criterion 2.1.2
  • Conformance level A

Rich Text Editor That Captures Tab With No Documented Escape

2.1.2 — No Keyboard Trap

Scenario

Setting

A grocery delivery app's shopping cart

What’s wrong

Rich-text editors capturing Tab for indentation with no documented/standard escape (and no advisory of the exit method).

Example 

notesEditor.addEventListener('keydown', (e) => {
  if (e.key === 'Tab') {
    e.preventDefault();
    document.execCommand('indent'); // Tab always indents the next substitution note; nothing tells the shopper how to leave
  }
});

Why it matters

A shopper using the rich-text substitution list to note a backup choice for each out-of-stock item presses Tab to reach the "Place order" button and instead indents another bullet, staying trapped in the notes field.

How to test

Tab into a rich-text editor and press Tab: if it's captured for indentation with no documented alternate exit key (and none is advised on screen), it fails.

How to fix

When Tab must be repurposed, document a standard exit like Escape and state it visibly next to the field.

notesEditor.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') { notesEditor.blur(); document.querySelector('.place-order-btn').focus(); return; }
  if (e.key === 'Tab') { e.preventDefault(); document.execCommand('indent'); }
});
<p class="hint">Press Esc, then Tab, to leave this field.</p>

Outcome

A shopper presses Escape, then Tab, and reaches the "Place order" button as expected.

Who is affected

Keyboard-only users can't escape a rich-text field that redefines Tab with no alternate exit key.

Learn more

Related scenarios