incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evangelos Vlachogiannis (JIRA)" <>
Subject [jira] Updated: (GRFT-102) Accessibility of portal content produced by authoring tool (kupu)
Date Fri, 15 Sep 2006 10:06:23 GMT
     [ ]

Evangelos Vlachogiannis updated GRFT-102:

    Attachment: patch.txt

I have replaced graffito kupu folder with kupu 1.3.5 "common" folder
contents and created the attached kupu.vm (I have only worked on the vm rest are just extracted
from puku dist. ). The editor looks fine but
when I post even if it seems to work (no error and redirect to folder
view on insert) I realized that it saves null content in db (meta looks
ok in db), so when i try to edit in iframe i get :

The server encountered an internal error () that prevented it from
fulfilling this request.

exception Error invoking method
    $Proxy30.getContentStream(Unknown Source)

> Accessibility of portal content produced by authoring tool (kupu)
> -----------------------------------------------------------------
>                 Key: GRFT-102
>                 URL:
>             Project: Graffito
>          Issue Type: Improvement
>          Components: Portlets
>         Environment: Now running on ie and mozilla but for accessibility should support
all browsers (maybe consider an applet editor ??)
>            Reporter: Evangelos Vlachogiannis
>            Priority: Minor
>         Attachments: patch.txt
> Current version of kupu html editor produces really very bad markup in terms of accessibility
but even for validity. For instance the font tag must really be avoided - use css style instead
(like new 1.3.5 ver does).  So a shift to the new version is a step towards better accessibility.
> Further, these are other relating problems that should be solved:
> 1. currently the editor portlet page in jetspeed contains 2 <html> tags which is
really unacceptable!!. 
> 2. Seeking for real xhtml (a base for accessibility) the editor should provide only semantic
markup. For example could provide strong instead of bold and emphasis instead of underline
or/and provide bold bolder etc using css.
> 3. For a portal creating content it actually means creating a page fragment. This means
that the editor should allow for global markup and also provide apropriate css classes for
styling according to JSR-168. 
> Well, most of the issues are actually concern the editor and I might submit also to kupu
but I find important to sync such work. This subject is actually one of my research interests
and could find more information of this work (Portal Accessibility Guidelines Extensions)

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message