Say you have a Web page with a textfield, WYSIWYG editor and a submit button. An author using a keyboard, will navigate into the textarea using the TAB key. Then they will use the TAB key to navigate into the WYSIWYG editor. Then they should be able to use the TAB key to navigate to the submit button. But if the WYSIWYG editor is using the TAB key for creating sublists or internal navigation, then the user will not be able to get to the submit button or another form control.

Some editors use the TAB key for internal navigation such as moving from cell to cell in a table. I’ve some cases where an author tabs into the editor and the focus is first set to the toolbar. So the author has to tab through all the buttons before they get into the content area.

The TAB key should only be used to move between form controls.

IE has the best support for keyboard navigation. Mozilla is currently developing a specification for supporting keyboard navigation for plug-ins. This API will then be adopted by Safari and Opera.

That’s the heading behaviour described above, I guess that also having the option in the drop-down allows the user to turn a heading into a paragraph (for example).

With regards to heading 1s, totally agreed, you’ll see that in the image example above, and in the later article on preventing problems.

Regarding tab, I understand that when using the form controls, but is it required for when in the editing area? It is common for JavaScript based editors to mimic Word in this regard, allowing people to use tab to nest a list, and even cntl-b for bold. I’m not convinced of the later (it interferers with bookmarks for me), but is tab a problem?

Also, editors should be able to hide the ability to create high level headers like h1 because these are created by the page template. For example, in XStandard, most developers remove h1 from styles.xml and label h2 as Heading and h3 as Sub-heading.

Pressing tab within a list creates a correctly nested list.

The TAB and SHIFT+TAB should be used for moving focus to other controls on the form. In XStandard, sublists are created via context menu.

To bring up a context menu in XStandard for OS X, it’s CONTROL+mouse click or CONTROL+SPACE.

Cool, thanks Alastair.

It is to an extent, it is something we’ve been through. If you think about the other applications people regularly use (e.g. word/textpad), it isn’t a new problem, just a different context.

There are three real solutions in a WYSIWYG context, two of which I consider better than any of the wiki or textile interfaces:

1. Using access keys or tabindex to make going from the text to the controls easier (not ideal, but a legitimate use of access keys).

2. Using a pop-up window of the controls, so it’s easy to alt-tab between the content and the controls.

3. Using a context menu (like right-click in word).

These are not mutually exclusive options either, you can use any or all and include user preferences as well.

I’ll cover this more in the keyboard accessibility post coming up later.

I’ve also been following this series with interest. I think a big problem with WYSIWYG editors is the separation of control from within the text. To me, actioning meaning/styling through buttons seems fairly impractical for AT users. It would probably entails jumping back and forth from buttons to textarea.

I can see that a screen reader user’s preference may be for meaning/styling to be applied while typing. Hence, you are left with some form of markup – HTML, Textile, Markdown, etc.

This is why I like live previews. The preview doesn’t really get in the way for screen reader users. As and when AT can pick up on DOM updates, they may provide a useful read-through preview, but you can do that in part by reading through the text in the textarea.

I guess it should be OK so long as the WYSIWYG editor allows users to markup on the fly (while typing) and the JavaScript doesn’t cause problems while typing.

I’m only testing the free version to start with, at the end I’ll try the full one to.

It is a weak-to-moderate usability issue if they aren’t separated, but I’ll try customising each as best I can (within what the documentation specifies).

The interesting ones for me will be keyboard (and screen reader) accessibility, and applying custom style templates (columns etc.), which I’ve got some ideas for that I haven’t seen implmented anywhere yet.

Oh, and you are right about the comments, I haven’t really changed them from the default install, they are next on the list of things to change. (I’ve also found the ‘subscribe to comments’ pluggin that Bruce Lawson uses, which I like.)