E-mail List Archives
Thread: RE: browser-based editor previously (no subject)
Number of posts in this thread: 1 (In chronological order)
From: Alastair Campbell
Date: Wed, Mar 29 2006 5:20AM
Subject: RE: browser-based editor previously (no subject)
No previous message | No next message
Kynn wrote:
> Such an interface has to pass both parts of the Authoring
> Tool Accessibility Guidelines -- the tool itself must be
> accessible, and the output must be accessible.
There are currently few (if any) options available for browser-based
editing that work with screen readers, except those that fall back to
plain text or a wiki style markup notation. I hunted for one for about 2
years until last year.
(NB: I didn't consider plain-text area fallbacks suitable, screen reader
users shouldn't need to know HTML anymore than anyone else.)
The popular free ones (FCKEditor, TinyMCE etc.) don't work with screen
readers (as in, you can't tell there is an editable area there. Tested
in JAWs). I'm not sure if it is their fault - I suspect the screen
readers need to catch up. Last time I checked, xstandard wasn't keyboard
accessible, although I think this was something they were going to work
on.
We have a particular need for a browser based WYSIWYG editor that works
with screen readers due to having internal users and clients using
screen readers. We had to overhaul one to work with our CMS, but I'm
afraid that is part of our CMS.
Our CMS editor would not fulfil ATAG 1 because we use one interface for
all, which requires JavaScript (that's the only problem). However, under
ATAG 2 it will probably be fine depending on how JavaScript is dealt
with in the WCAG 2. Controversial I know, but we have a known user base
that generally wouldn't know what to do with a text-area! (It's a hidden
function for developers that can be shown with a user-CSS file, and
could *potentially* be added for clients, although I'd rather not.)
It really depends on your requirements, if it is interoperability &
mobile access that worries you then something that falls back to a
text-area would be your only choice. If it is (practical) accessibility
*and* usability that is the issue, then overhauling a current open
source JavaScript one is probably the best option.
The only other useful option I know of is not to use a browser based
editor, but something that translates to a word or open office template
and back.
Kind regards,
-Alastair
--
Alastair Campbell | Director of User Experience
Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html