Tabs: simple manipulation accessibility

Additionally, after adding a tab focus is set to first focusable element in DOM.

After adding a tab focus should be set to 'Add' link, or to new tab.

I've looked into this for a while. Since Tabs manage focus inside the widget, the remove button would've to be integrated into that focus handling, otherwise each tab's close button would be able to receive focus, breaking the keyboard navigation of the tabs themselves. How would you trigger a close when the close button can't be tabbed to? Would the cursor handling move focus to the close button, then to the next tab? Or bind escape key to close the active tab, and give the close span role="presentation" to hide it from screenreaders?

Since the manipulation is just a demo and not an actual part of the widget, do we really want to implement that in the demo?

If we keep/update it, the add dialog needs to handle the submit event - tabbing to the add button shouldn't be necessary.

From ARIA Authoring Practices:

Alt+Del - When deletion is allowed, with focus anywhere within the tab panel, pressing alt-del will delete the current tab and tab panel from the tabbed interface control. If additional tabs remain in the tabbed interface, focus goes to the next tab in the tab list. An alternative to providing a keystroke to close a tab is to provide a context menu that is associated with the tab title. When focus is on the tab, pressing Shift+F10 or pressing the right mouse button will open a context menu with the close choice

We should implement the Alt+Del functionality.

As for not having to tab to the Add button, that's already implemented. The dialog has a form and submitting the form adds the tab. However, the last field is a textarea, so pressing enter won't submit the form.

Tabs: Update manipulation demo - implement alt+del shortcut to remove active tab. Fixes #7847 - Tabs: simple manipulation accessibility

Changeset: e3ab5f811a97c9fd79038c550aa86dcff0465d40