The second building block of a modern WYSIWYG editor is how the styles are defined and added. Styles should be applied by class to standard HTML, but what kind of import methods would be best, and how would they surface in the interface?

Starting from the building blocks, what should an editor allow? Most of the browser based editors allow people to edit the source HTML. To make sure the code stays valid, the editor will have to filter what gets saved, so what HTML should it allow?

This is the overview that outlines the accessibility guidelines that affect a “What You See Is What You Get” editor (WYSIWYG) editor, and do a top-line evaluation of an editor so that you know what to look for. Setting the scene for a set of posts specifying accessible WYSIWYG editors.

There is an elephant in the corner type of problem in the accessibilty world, that of WYSIWYG editors. In the first of a three part series, I outline this problem. The later posts will define what a solution would be, and see if it exists yet.