[jira] Commented: (GRFT-102) Accessibility of portal content produced by authoring tool (kupu)
[ 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 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)
[ 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 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)
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) <[EMAIL PROTECTED]> 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 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
Re: [jira] Commented: (GRFT-102) Accessibility of portal content produced by authoring tool (kupu)
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) <[EMAIL PROTECTED]> 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 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)
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. Christophe On 10/14/06, Evangelos Vlachogiannis <[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]> 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 >> 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)
Hi Christophe, I have just added that param but nothing changed. Here is my config: maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443" acceptCount="100" connectionTimeout="2" 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. Christophe On 10/14/06, Evangelos Vlachogiannis <[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]> 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 >> 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 ---
