You are viewing a plain text version of this content. The canonical link for it is here.
Posted to graffito-dev@incubator.apache.org by "Evangelos Vlachogiannis (JIRA)" <ji...@apache.org> on 2006/09/15 09:30:23 UTC
[jira] Created: (GRFT-102) Accessibility of portal content produced
by authoring tool (kupu)
Accessibility of portal content produced by authoring tool (kupu)
-----------------------------------------------------------------
Key: GRFT-102
URL: http://issues.apache.org/jira/browse/GRFT-102
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
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) at http://www.syros.aegean.gr/users/evlach/page/
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (GRFT-102) Accessibility of portal content
produced by authoring tool (kupu)
Posted by Evangelos Vlachogiannis <ev...@aegean.gr>.
Hi Christophe,
I have just added that param but nothing changed. Here is my config:
<Connector port="9090" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true"
emptySessionPath="true"/>
Thanks,
Vangelis
Christophe Lombart wrote:
> Hi,
>
> That's strange.
>
> Do you have the emptySessionPath="true" in the tomcat server.xml ? the
> kupu editor is using a servlet which requires to share the session
> with the portlet.
>
> <Connector port="8080" maxHttpHeaderSize="8192"
> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
> enableLookups="false" redirectPort="8443" acceptCount="100"
> connectionTimeout="20000" disableUploadTimeout="true"
> emptySessionPath="true" />
>
> Christophe
>
>
> On 10/14/06, Evangelos Vlachogiannis <ev...@aegean.gr> wrote:
>> Hi Christophe,
>>
>> should I config something before using it?
>>
>> Graffito Content Browser on edit mode it says "No content found in this
>> folder. Use the edit mode to add new content." and whatever tab I press
>> nothing happens. I guess I miss something here...
>>
>> regards,
>> Vangelis
>>
>> Christophe Lombart wrote:
>> > Thanks you very much for your help
>> > In order to support put method instead of post, there are a couple of
>> > major changes.
>> >
>> > On 10/13/06, Evangelos Vlachogiannis (JIRA) <ji...@apache.org> wrote:
>> >> [
>> >>
>> http://issues.apache.org/jira/browse/GRFT-102?page=comments#action_12442060
>>
>> >> ]
>> >>
>> >> Evangelos Vlachogiannis commented on GRFT-102:
>> >> ----------------------------------------------
>> >>
>> >> Thanks a lot for that Christophe. I ll test that, try to understand
>> >> changes and take it further asap.
>> >>
>> >> > Accessibility of portal content produced by authoring tool (kupu)
>> >> > -----------------------------------------------------------------
>> >> >
>> >> > Key: GRFT-102
>> >> > URL: http://issues.apache.org/jira/browse/GRFT-102
>> >> > 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)
>> >> at http://www.syros.aegean.gr/users/evlach/page/
>> >>
>> >> --
>> >> This message is automatically generated by JIRA.
>> >> -
>> >> If you think it was sent incorrectly contact one of the
>> >> administrators:
>> http://issues.apache.org/jira/secure/Administrators.jspa
>> >> -
>> >> For more information on JIRA, see:
>> http://www.atlassian.com/software/jira
>> >>
>> >>
>> >>
>> >
>> >
>>
>> --
>> Evangelos Vlachogiannis
>> Researcher - University of the Aegean
>> Contact&More: http://www.syros.aegean.gr/users/evlach/contactme.php
>>
>
>
--
---------------------------------------------------------------
Evangelos Vlachogiannis
Researcher - PhD. Candidate
Contact: http://www.syros.aegean.gr/users/evlach/contactme.php
---------------------------------------------------------------
Re: [jira] Commented: (GRFT-102) Accessibility of portal content produced by authoring tool (kupu)
Posted by Christophe Lombart <ch...@gmail.com>.
Hi,
That's strange.
Do you have the emptySessionPath="true" in the tomcat server.xml ? the
kupu editor is using a servlet which requires to share the session
with the portlet.
<Connector port="8080" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true"
emptySessionPath="true" />
Christophe
On 10/14/06, Evangelos Vlachogiannis <ev...@aegean.gr> wrote:
> Hi Christophe,
>
> should I config something before using it?
>
> Graffito Content Browser on edit mode it says "No content found in this
> folder. Use the edit mode to add new content." and whatever tab I press
> nothing happens. I guess I miss something here...
>
> regards,
> Vangelis
>
> Christophe Lombart wrote:
> > Thanks you very much for your help
> > In order to support put method instead of post, there are a couple of
> > major changes.
> >
> > On 10/13/06, Evangelos Vlachogiannis (JIRA) <ji...@apache.org> wrote:
> >> [
> >> http://issues.apache.org/jira/browse/GRFT-102?page=comments#action_12442060
> >> ]
> >>
> >> Evangelos Vlachogiannis commented on GRFT-102:
> >> ----------------------------------------------
> >>
> >> Thanks a lot for that Christophe. I ll test that, try to understand
> >> changes and take it further asap.
> >>
> >> > Accessibility of portal content produced by authoring tool (kupu)
> >> > -----------------------------------------------------------------
> >> >
> >> > Key: GRFT-102
> >> > URL: http://issues.apache.org/jira/browse/GRFT-102
> >> > 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)
> >> at http://www.syros.aegean.gr/users/evlach/page/
> >>
> >> --
> >> This message is automatically generated by JIRA.
> >> -
> >> If you think it was sent incorrectly contact one of the
> >> administrators: http://issues.apache.org/jira/secure/Administrators.jspa
> >> -
> >> For more information on JIRA, see: http://www.atlassian.com/software/jira
> >>
> >>
> >>
> >
> >
>
> --
> Evangelos Vlachogiannis
> Researcher - University of the Aegean
> Contact&More: http://www.syros.aegean.gr/users/evlach/contactme.php
>
--
Best regards,
Christophe
Re: [jira] Commented: (GRFT-102) Accessibility of portal content
produced by authoring tool (kupu)
Posted by Evangelos Vlachogiannis <ev...@aegean.gr>.
Hi Christophe,
should I config something before using it?
Graffito Content Browser on edit mode it says "No content found in this
folder. Use the edit mode to add new content." and whatever tab I press
nothing happens. I guess I miss something here...
regards,
Vangelis
Christophe Lombart wrote:
> Thanks you very much for your help
> In order to support put method instead of post, there are a couple of
> major changes.
>
> On 10/13/06, Evangelos Vlachogiannis (JIRA) <ji...@apache.org> wrote:
>> [
>> http://issues.apache.org/jira/browse/GRFT-102?page=comments#action_12442060
>> ]
>>
>> Evangelos Vlachogiannis commented on GRFT-102:
>> ----------------------------------------------
>>
>> Thanks a lot for that Christophe. I ll test that, try to understand
>> changes and take it further asap.
>>
>> > Accessibility of portal content produced by authoring tool (kupu)
>> > -----------------------------------------------------------------
>> >
>> > Key: GRFT-102
>> > URL: http://issues.apache.org/jira/browse/GRFT-102
>> > 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)
>> at http://www.syros.aegean.gr/users/evlach/page/
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> If you think it was sent incorrectly contact one of the
>> administrators: http://issues.apache.org/jira/secure/Administrators.jspa
>> -
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>>
>>
>
>
--
Evangelos Vlachogiannis
Researcher - University of the Aegean
Contact&More: http://www.syros.aegean.gr/users/evlach/contactme.php
Re: [jira] Commented: (GRFT-102) Accessibility of portal content produced by authoring tool (kupu)
Posted by Christophe Lombart <ch...@gmail.com>.
Thanks you very much for your help
In order to support put method instead of post, there are a couple of
major changes.
On 10/13/06, Evangelos Vlachogiannis (JIRA) <ji...@apache.org> wrote:
> [ http://issues.apache.org/jira/browse/GRFT-102?page=comments#action_12442060 ]
>
> Evangelos Vlachogiannis commented on GRFT-102:
> ----------------------------------------------
>
> Thanks a lot for that Christophe. I ll test that, try to understand changes and take it further asap.
>
> > Accessibility of portal content produced by authoring tool (kupu)
> > -----------------------------------------------------------------
> >
> > Key: GRFT-102
> > URL: http://issues.apache.org/jira/browse/GRFT-102
> > 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) at http://www.syros.aegean.gr/users/evlach/page/
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>
--
Best regards,
Christophe
[jira] Commented: (GRFT-102) Accessibility of portal content
produced by authoring tool (kupu)
Posted by "Christophe Lombart (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/GRFT-102?page=comments#action_12442033 ]
Christophe Lombart commented on GRFT-102:
-----------------------------------------
I have to stop this issue for more urgent work.
I have migrated to kupu 1.3.5.
So now it is ready to work on the accessibility.
Evangelos,
Can you work on that ?
> Accessibility of portal content produced by authoring tool (kupu)
> -----------------------------------------------------------------
>
> Key: GRFT-102
> URL: http://issues.apache.org/jira/browse/GRFT-102
> 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
> Assigned To: Christophe Lombart
> 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) at http://www.syros.aegean.gr/users/evlach/page/
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GRFT-102) Accessibility of portal content
produced by authoring tool (kupu)
Posted by "Christophe Lombart (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/GRFT-102?page=all ]
Christophe Lombart reassigned GRFT-102:
---------------------------------------
Assignee: (was: Christophe Lombart)
> Accessibility of portal content produced by authoring tool (kupu)
> -----------------------------------------------------------------
>
> Key: GRFT-102
> URL: http://issues.apache.org/jira/browse/GRFT-102
> 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) at http://www.syros.aegean.gr/users/evlach/page/
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GRFT-102) Accessibility of portal content
produced by authoring tool (kupu)
Posted by "Christophe Lombart (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/GRFT-102?page=all ]
Christophe Lombart reassigned GRFT-102:
---------------------------------------
Assignee: Christophe Lombart
> Accessibility of portal content produced by authoring tool (kupu)
> -----------------------------------------------------------------
>
> Key: GRFT-102
> URL: http://issues.apache.org/jira/browse/GRFT-102
> 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
> Assigned To: Christophe Lombart
> 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) at http://www.syros.aegean.gr/users/evlach/page/
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GRFT-102) Accessibility of portal content
produced by authoring tool (kupu)
Posted by "Evangelos Vlachogiannis (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/GRFT-102?page=comments#action_12442060 ]
Evangelos Vlachogiannis commented on GRFT-102:
----------------------------------------------
Thanks a lot for that Christophe. I ll test that, try to understand changes and take it further asap.
> Accessibility of portal content produced by authoring tool (kupu)
> -----------------------------------------------------------------
>
> Key: GRFT-102
> URL: http://issues.apache.org/jira/browse/GRFT-102
> 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) at http://www.syros.aegean.gr/users/evlach/page/
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GRFT-102) Accessibility of portal content produced
by authoring tool (kupu)
Posted by "Evangelos Vlachogiannis (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/GRFT-102?page=all ]
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
org.apache.ojb.broker.PersistenceBrokerException: Error invoking method
getContentStream
org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl.invoke(IndirectionHandlerDefaultImpl.java:334)
$Proxy30.getContentStream(Unknown Source)
org.apache.portals.graffito.servlets.GraffitoViewerServlet.doGet(GraffitoViewerServlet.java:67)
javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
----
> Accessibility of portal content produced by authoring tool (kupu)
> -----------------------------------------------------------------
>
> Key: GRFT-102
> URL: http://issues.apache.org/jira/browse/GRFT-102
> 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) at http://www.syros.aegean.gr/users/evlach/page/
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira