The accessibility of the interface is just as important as the accessibility of the code the editor outputs. The key aspects to focus on are the ‘perceptability’ of controls (e.g. alt text) and ease of using a keyboard only. Currently, I haven’t found a browser based WYSIWYG editor that is keyboard accessible out of the box [1], so I’ve been looking at the Authoring Tool guidelines quite a lot as they will flesh out more than I’ve had experience with.
Perceptability
In W3C terms: the Interface must be Perceivable
, which can be thought of separately from the interaction being possible. For example, if images are used for buttons, they need alternative text. That isn’t just for the controls (usually toolbars), but for the ‘what you see’ content area preview, so that when you’ve added an image with alt text, you can access that as content.
If the interface uses pop-ups or other dialogues, these should also be accessible, so if they use HTML, the form controls and structure should comply with the content guidelines.
The much better known web content accessibility guidelines apply to this, and I don’t think it’s necessary to repeat those here.
Keyboard accessibility
ATAG 2 provides a good outline of what you need for keyboard accessibility, things like:
- You must be able to operate the editor with a keyboard only.
- Navigating through items does not activate them.
- You must allow navigation between controls, and around the editing interface.
- Allow people to save settings between sessions, and preferably be able to import/export those settings.
Assuming the you can navigate around the text with the keyboard, there is one primary issue that you need to get right for editing with a keyboard: Applying styles to a selection of text, and inserting items to a particular location.
The difficult aspect is that you generally need to be able to select a some text, and then move to the toolbar without affecting your current selection. There are three principle methods I can think of that might be viable within a browser based environment:
- Keyboard short-cuts, e.g. accesskeys or binding keys to functions with JavaScript.
- A new window for the toolbar, so you can switch from the editing window to the control window.
- A context menu, so that you can open the possible controls without leaving the selection area.
Although many screen readers allow you to separate the keyboard cursor from the location, but not everyone on a keyboard uses a screen reader, so you can’t rely on that. The mechanisms above would make using a screen reader with the editor much easier anyway.
Keyboard short-cuts
This is my least preferred method due to the major limitations of accesskeys, which is mainly that they tend to clash with user-agent functionality. Using JavaScript to provide the short-cuts wouldn’t be any better, and possibly more flaky with cross browser issues in assigning keys to actions. The ATAG 2 guideline says observe the accessibility conventions of the platform
, which may not help very much at the moment, as within browsers they are not consistent yet.
These issues could be overcome by allowing user’s to assign keys themselves, in which case it might be a reasonable option.
New window for controls
Something of a kludge, but one method would be to pop-open a new window that contains the controls, so that you would edit in one window, and switch to the control window to add or adjust things. The advantage is that this is quite simple to do (with JavaScript) and allows an easy switching back and forth.
Context menu
This may be the hardest method to implement accessibly, but it would also be the most usable.
At any point where editing, the user could call up the context menu (there is a dedicated key in Windows, you’d probably have to assign one for OSX or Linux). That menu would have the same options as the control bar/buttons, ideally it would would only show those that are relevant. For example, if there is text selected then the inline options would be available.
This was covered before in a slightly different context for adding structural code. Given the number of options that might be available, it would probably have to be a cascading menu.
Which option would be best?
These three options are not mutually exclusive, in fact, you could happily provide all three. However, I think the context menu is the most beneficial if it can be done, as it would be useful for everyone.
I thought there was going to be more to write for this post, but I think the tricky bit is implementing it, not defining what it should be.
Footnotes
- 1
- At work we have hacked an open source one to make it keyboard accessible, but it wasn’t easy to do.
Technorati Tags: