W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2002


From: Charles F. Munat <chas@munat.com>
Date: Fri, 25 Jan 2002 22:06:37 -0800
Message-ID: <3C52476D.2060500@munat.com>
To: w3c-wai-ig@w3.org

Carol Foster wrote:

> In the case where these tools are used to create content management systems,
> though, the responsibility for creating accessible content gets spread
> around. We try within the usual constraints to create accessible "templates"
> for our sites, and I am always pushing for greater levels of accessibility.

The big difficulty here is that usually the content providers are adding 
text via a form. So they type their content into some sort of text box, 
or they upload a plain text file. Then the PHP/Cold Fusion is used to 
parse this file and create the web page.

With a text box, at best the content provider is inputing one paragraph 
at a time. But this limits the PHP to block level elements. How does the 
content provider indicate when something is to be a link? Clearly, he or 
she needs to know at least some code.

If you limit the CP (content provider) to coding links and other inline 
elements, you can probably improve accessibility using such a system. 
The farther you can keep the content provider from the presentational 
elements of a page (and from the code!), the better. But ideally, you 
would eliminate all code knowledge completely, and your input system 
would guide the CP through the creation of a document.

I have been slowly (VERY slowly) working on a content management system 
that uses XML/XSP/XSL and Enterprise Java Beans. It is still in the 
design stage (no code yet). But here is my idea:

The content provider is presented with a wizard (this could be a series 
of web pages, or better yet, an app that runs on the client). The wizard 
asks what type of content will be provided. Perhaps there's a drop down 
list with things like article, essay, news item, tutorial, newsletter, 
book, etc. When the CP selects a type of content, the wizard uses the 
appropriate XML-based grammar for that content. For example, if the 
content type was a news item, the wizard might switch to NewsML (or NITF).

The wizard would then prompt the CP for the appropriate metadata (title, 
author, date, keywords, publisher, copyright, etc.). After that it would 
open a basic text editor.

The CP would then enter the text. As she entered the text, she could 
highlight passages and right-click (or keyboard equivalent) on them. 
This would produce a menu of options such as link, lang, emphasis, etc. 
The options would depend on the XML grammar, of course. When one was 
selected, the wizard would then prompt the CP for more information (url, 
etc.), if necessary, using a dialog box.

Ideally, spell and grammar checking would be performed as the text was 
entered. If a word was not recognized, an alert would pop up offering 
other spelling options *or* the option of designating a foreign language 
(which would add the span or em or equivalent element automatically). 
And so on.

When the page was done (or at any time) it could be previewed using the 
current stylesheet. The CP would have no control over style (and 
attempts to add code via the text would be ignored). Once the page was 
completed and checked, either the CP could post it or the system might 
be set to require someone else's approval first (the page would be 
staged until then).

The final output could be dumped into a database, or an XML file could 
be produced (or any of a variety of other options).

Another part of the content management system would allow the designers 
to control the site stylesheets. But the HTML code would be pre-built to 
convert the XML into accessible code (using XSL, or to just output the 
XML). Thus accessibility/usability is preserved (and encouraged).

But this is a huge project and I am way too busy to get it done now. I'm 
working on it slowly while hoping that some open source project will do 
most of the work (and I can just come in an adapt it to my needs). If I 
ever do finish this, I'll open source it.

That's one idea, anyway.

(Oh, the content types would be modular, so as new XML grammars became 
available, the new functionality could be just plugged in. This would 
also allow the system to be adapted to the needs of a particular site. 
Services could be plugged in similarly.)

The impetus behind this was to find a way to make it easy for non-profit 
organizations (and small businesses) to create state-of-the-art web 
sites with low start-up costs while maintaining accessibility. I built a 
similar (but much more primitive) content management system two years 
ago using Cold Fusion. (But you need a stinking CF server, which gets 
expensive.) My next version will be Java and W3C technologies. (I have 
considered PHP or Python, but Java is more powerful.)

Charles F. Munat
Seattle, Washington

(If anyone is interested in starting such an open source project, please 
let me know... I can give a more detailed description.)
Received on Saturday, 26 January 2002 01:05:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:36:07 UTC