Re: portals

Geoff is right on many of these points, a major problem in CMS is 
maintaining standards of content authored by empowered non-web designers. 
This causes problems because of the way a lot of users see web authoring 
as similar to word processing.

Plone has several things in the pipeline to deal with this. The first of 
which is the soon to be integrated Epoz editor. This is a WYSIWYG get 
editor which works with the IE and Moz WYSIWYG widgets. The team who work 
on that have spent a lot of time on ensuring that all the code is XHTML. I 
have also been consulted to help them develop a system which enforces an 
administator set site policy. So for example if an adminstrator chooses 
WCAG-AA compliance as the site policy the editor should remind people to 
enter necessary information to comply with that (obviously it can't be 
enforced since not everything _needs_ an alt tag, so some things that 
might may not get one), the aim being to make it harder for people to 
ignore information they might need to add it. There is also a word-paste 
feature which captures word pastes and strips it clean as it goes in 
rather than retroactively doing it. This helps the user see what is really 
going on, since there is always the risk that the look of the content 
might be changed.

I am also working to develop an accessibility assistant which plugs into 
the workflow system. This would help people run queries on individual 
pages before publishing or allow audits of an entire site. The workflow 
system is very powerful and it is easly conceavable that people could be 
stopped from publishing content on the site until someone reponsible for 
accessibility has ok'd it. Alternatively the accessibility checker could 
allow them to sign their name to a report of the checked elements, so if 
inaccessible pages are published someone is accountable. This fits in very 
much with the Plone ethos of standards and style enforcement. In our a 
community there is a big move towards using the most current standards and 
best practice, and helping our users to use them too with guides and 
tools. Almost all the tools we produce have some kind of "online" help.

There are probably a few more things going on which would help this if 
anyone is interest there are people who can answer such questions on the 
#plone IRC channel on the irc.freenode.net servers.


Tom

On Thu, 9 Oct 2003 23:26:46 +1000, Geoff Deering <gdeering@acslink.net.au> 
wrote:

> The difficult area for portals or CMSs to address web standards and WAI 
> is
> the methods used for users to add content.  Taken that the web developers
> have produced templates that conform to a W3C grammar, and it has no 
> major
> inaccessibility issues, it is at the stage when users add, modify or edit
> the content that it becomes very difficult to manage and keep markup
> consistent with any formal grammar/dtd.
>
> In most CMS systems this is done via a textarea, which is the place where
> users insert their content in the document.  Many CMS have something like
> htmlarea as a toolbar that will allow the user to markup the document.
> Mostly it is HTML soup.  Some CMS do this and then have a Tidy plugin to
> clean up the markup.  There are also other plugins in various CMSs that 
> can
> find ABBRs and wrap that tag around them and add a title attribute with
> meaning of the ABBR.  There are many similar plugins to help quality 
> control
> user content, but it is very difficult to do this and maintain documents
> with correct and proper structure.
>
> Anything beyond basic paragraphs with bold and italics and URLs, such as
> lists and tables are very difficult for users to build without coding 
> HTML.
> As far as I know there is no one quite addressing this issue (maybe 
> BitFlux,
> but I haven’t tried it).  I don’t know what Plone does to address this 
> issue
> (Tom)?  Apache/Cocoon/Lenya I think is probably the best framework for
> delivering content in a dynamic way, but Lenya is not yet ready for prime
> time, and its not a trivial system, it’s an advanced publishing 
> framework.
> There are a lot of other products that do a pretty good job, but I don’t
> think there is anything out there that one can say is really mature
> addressing these concerns?
>
> Geoff
>
> -----Original Message-----
> From: Charles McCathieNevile
>
>
>
> Well, nothing needs to be done differently from producing accessible 
> stuff
> in general, but there are a few things to keep especially in mind...
>
> You are essentially trying to provide access to a lot of information. 
> Some
> relevant checkpoints from WCAG 1.0 and some (personal, of course) 
> thoughts
> on applying them:
>
> Tables:
> <?color><?param 0000,0000,CCCC>5.1 <?/color> For data tables, identify 
> row
> and column headers.
>
>  Tables are a good way to organise information, but you need to make them
> right. As well as th elements in appropriate places, think about how the
> table will read...
>
> <?color><?param 0000,0000,CCCC>5.2 <?/color> For data tables that have 
> two
> or more logical levels of row or column headers, use markup to associate
> data cells and header cells.
> <?color><?param 0000,0000,CCCC>11.2 <?/color> Avoid deprecated features 
> of
> W3C technologies.
> <?color><?param 0000,0000,CCCC>5.5 <?/color> Provide summaries for 
> tables.
> <?color><?param 0000,0000,CCCC>5.6 <?/color> Provide abbreviations for
> header labels.
>
> Or maybe a flatter structure:
> <?color><?param 0000,0000,CCCC>3.5 <?/color> Use header elements to 
> convey
> document structure and use them according to specification.
> <?color><?param 0000,0000,CCCC>3.6 <?/color> Mark up lists and list items
> properly.
>
> The following really should be obvious...
> <?color><?param 0000,0000,CCCC>13.5 <?/color> Provide navigation bars to
> highlight and give access to the navigation mechanism.
> <?color><?param 0000,0000,CCCC>13.6 <?/color> Group related links, 
> identify
> the group (for user agents), and, until user agents do so, provide a way 
> to
> bypass the group.
>
> Especially for Portals:
> <?color><?param 0000,0000,CCCC>13.7 <?/color> If search functions are
> provided, enable different types of searches for different skill levels 
> and
> preferences.
>
> Essentially a portal IS a search function. One trick is to allow for 
> broad
> searching and for deep searching - different people find different
> approaches more successful. There is research by Inmaculada Fajardo that 
> you
> could quote here:  http://www.ugr.es/~ergocogn/articulos/towards.pdf as a
> semi-random starting point...
>
> This is the sort of thing that people use semantic web techniques for -
> having something as simple as Dublin Core metadata about the things you 
> are
> pointing to means you can build portals that provide multiple paths to 
> the
> same information - optionally giving people the choice to switch between
> different restricted sets. See also <?color><?param 0000,0000,CCCC>13.9
> <?/color> Provide information about document collections (i.e., documents
> comprising multiple pages.) and <?color><?param 0000,0000,CCCB>13.2
> <?/color> Provide metadata to add semantic information to pages and 
> sites.
>
> Doing this is also helpful because you can export your information 
> directly
> to other systems - allowing people to build the functionality of your 
> portal
> into things they already use. One approach to this is the work done in 
> Amaya
> derived from the Annotea project, which is essentially about bookmarks 
> (or
> personal portals if you prefer to think of them that way). A somewhat
> technical explanation is at 
> http://www.w3.org/2003/07/Annotea/BookmarkSchema
>
> Writing style is important - enough information and not too much is a 
> hard
> thing to measure, but important.
> <?color><?param 0000,0000,CCCC>13.8 <?/color> Place distinguishing
> information at the beginning of headings, paragraphs, lists, etc.
> <?color><?param 0000,0000,CCCC>12.3 <?/color> Divide large blocks of
> information into more manageable groups where natural and appropriate.
> <?color><?param 0000,0000,CCCC>13.1 <?/color> Clearly identify the 
> target of
> each link.
> <?color><?param 0000,0000,CCCC>14.1 <?/color> Use the clearest and 
> simplest
> language appropriate for a site's content.
> <?color><?param 0000,0000,CCCC>14.2 <?/color> Supplement text with 
> graphic
> or auditory presentations where they will facilitate comprehension of the
> page.
> Icons that can be understood on their own are notoriously hard to make, 
> but
> can be helpful if used with other cues. For an extreme example (designed 
> for
> people who have minimal reading skills) see http://www.peepo.com
>
> And when you've got this right, done the obvious things (valid code, text
> alternatives, not relied on javascripts or Flash or something) then you 
> just
> go through the checklist - 
> http://www.w3.org/TR/WCAG10/full-checklist.html -
> for things you may have missed.
>
> It seems daunting the first time, but you get used to it pretty quickly.
> Then the trap is thinking you know what you're doing and forgetting to 
> check
> (at least that's a problem I find is hard to avoid, which is why I still
> check everything. Even if I know I haven't one everything I often find
> simple stuff I can do quickly to make things better).
>
> Oh, talking to users is helpful. There are lots of different users of
> course, so you need to be sure that you aren't just listening to a 
> couple of
> sides of a complex story, but adding a couple of random insights to what 
> you
> already knew isn't necessarily a bad thing...
>
> cheers
>
> Chaals
>
> On Wednesday, Oct 8, 2003, at 09:33 US/Pacific, FOX, Jake wrote:
>
> Hi guys,
>
> does anyone know if there are any specific accessibility issues to keep 
> in
> mind when producing a web portal?
> Does anything need to be done any differently?
>
> All feedback is very much appreciated.
>
> Many thanks,
>
> -Jake.
>
> --------------------------------
> Jake Fox
> Web Analyst
> Group Web Solutions
>
> Norwich Union
> Floor 3 - East Wing
> Sentinel House
> 37 Surrey Street
> Norwich
> Norfolk
> NR1 2UZ
>
> Tel: +44 (0)1603 686333
> Fax: +44 (0)1603 840618
>
> email: foxj@norwich-union.co.uk
> website: http://www.norwichunion.com
> intranet: http://websolutions.intra.norwich-union.com
>
>
>
>
> **********************************************************************
> This email and any files sent with it are intended only for the named
> recipient. If you are not the named recipient please telephone/email
> the sender immediately. You should not disclose the content or
> take/retain/distribute any copies.
> **********************************************************************
>
>
>
> Norwich Union Life & Pensions Limited
> Registered Office: 2 Rougier Street, York, YO90 1UU
> Registered in England Number 3253947
> A member of the Norwich Union Marketing Group
> Members of which are Authorised and Regulated by the Financial Services
> Authority.
>
> For further enquiries 01603 622200
>
>
> --
> Charles McCathieNevile Fundación Sidar
> charles@sidar.org http://www.sidar.org

Received on Thursday, 9 October 2003 10:11:33 UTC