• twitter image
  • facebook image
  • youtube image
  • linkedin image
Language: CMS Made Simple Czech CMS Made Simple France CMS Made Simple Spain CMS Made Simple Hungary CMS Made Simple Russia CMS Made Simple Netherlands

All times are UTC




Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 9 posts ] 
Author Message
 Post subject: Accessibility issues with code-output
PostPosted: Fri Jan 06, 2006 5:33 pm 
Offline
Power Poster
Power Poster

Joined: Wed Sep 08, 2004 3:32 pm
Posts: 520
Finally I found some time to write down some issues I had when setting up the NatKo project as well as with Ansichtssache / Viewpoint.

All of the below is related to the output, not the backend. However, quite a lot of modules are affected and I try to explain the reasons:

  • Navigation
    Using the bulletmenu for navigation it was quite complex to make it work according to W3C WCAG. If you follow a link and get to the respective page, the link must not be active, i.e. it must not even be a link. However there is another issue with this as WCAG says that a user has to clearly identify where he / she is within the website. I hacked my way through it, but not very modular ... it just works.
  • Sitemap / Breadcrumb
    Same rules as for navigation: Had to hack my way through it to make it work. Seems to apply to all kinds of navigation mechanisms used in CMSMS. Something I really miss is the possibility to have extra fields in the content-section where you could specify values for additional attributes like title if you link to this website from sitemap, breadcrumb, navigation, etc.
  • Form fields
    Forms are pretty difficult - at least in the beginning. All forms used within CMSMS that I have seen so far do not conform to WCAG. There are certain tags, such as fieldset, legend and label that must be used. Took me quite a bit to get this working. Especially in modules such as bookmarks, etc.
  • WYSIWYG editor
    I am still waiting for Xinha to be integrated into CMSMS. Actually most customers are overwhelmed by the possibilities offered in FCK or other editors. So I used widgEditor but this one does not work with CMSMS image manager and link manager. And it did not support use of smarty-tags in the content field. While I got the latter working with lots of efforts, I was not able to integrate image- and link manager. But a good WYSIWYG editor with valid source-output would be really good. When it comes to ATAG later (hopefully) this will be the most crucial point.
  • Search / Search results
    While there was not integrated search I hacked together a script consisting of multiple solutions. The output of search-results therefore was a bit tricky. The user should be able to sort the results according to his / her needs. Couldn't get that working within my projects. However I mangaged to generate an ordered list
      for output. But something more sophisticated for search input and output would be highly recommended.
    1. News / Events
      Both modules were kind of buggy when I used them. Don't know if the handling is better now. Had to hack my way through the scripts to get rid of
      and all kinds of rubbish code in there. Not very semantic. Especially events. Had to recode the list-output so that it renders without tables but with definition lists. The calendar itself should be a data-table and marked-up as such.
    2. Clean-URLs
      One of the things I could not get rid off were messy URLs when using modules. I would highly appreciate a solution for clean URLs - maybe someone comes up with a good idea.
    3. Just one wish ...
      It would be pretty cool to have Tidy integrated into CMSMS, maybe even within the pre-render process to validate the source, remove unwanted elements and do stuff like that. As far as I'm concerned I know my tools and manage to validate a page. But most end-users of CMSMS don't. And they might need some help.

That was it for today. Almost all of the above was taken from my work on NatKo project. Some other issues are related to Ansichtssache / Viewpoint. There's still some work to do but CMSMS is already pretty good when it comes to valid code and ease of use.

Regards,
Nils


Top
  Profile  
 
Share On:
Share on Facebook Share on Twitter Share on Google+
 Post subject: Re: Accessibility issues with code-output
PostPosted: Fri Jan 06, 2006 7:10 pm 
Offline
Power Poster
Power Poster

Joined: Sat Sep 10, 2005 4:45 pm
Posts: 650
Location: Växjö, Sweden
Thanks a lot, Nils! This is the kind of feedback that we need to make CMSMS comply to accessibility standards! :D

Quote:
Navigation
Using the bulletmenu for navigation it was quite complex to make it work according to W3C WCAG. If you follow a link and get to the respective page, the link must not be active, i.e. it must not even be a link. However there is another issue with this as WCAG says that a user has to clearly identify where he / she is within the website. I hacked my way through it, but not very modular ... it just works.


That's cool. Would you mind sharing how you solved this and other accessibility issues? I'm sure you even could be given access to work towards the core in svn to work on accessibililty issues such as this. I for one would be very happy to see these things implemented in the core. ;D


Quote:
Sitemap / Breadcrumb
Same rules as for navigation: Had to hack my way through it to make it work. Seems to apply to all kinds of navigation mechanisms used in CMSMS. Something I really miss is the possibility to have extra fields in the content-section where you could specify values for additional attributes like title if you link to this website from sitemap, breadcrumb, navigation, etc.


What did you change with breadcrumbs? Looking at the NatKo site source code I can't see any difference from what the code that the breadcrumbs I'm using on other sites look like.

As for adding attributes in the content section, that's a good idea. We've been discussing to add a field where the ID for a menu item can be entered, thus allowing to for example use background images through CSS for each menu item.

Could you give concrete examples of what fields you would like to be added and how these would alter the code that for example bulletmenu outputs?

Pimenu is very customizable, but as it lacks an admin interface I find it much too difficult to use, if not using any of the sample templates. Especially since my German is not very good and there is no short version of the documentation. If there could be an admin interface for pimenu where the user can make the template that would be easier to use, and would give lots of freedom to select what code the menu outputs.

Piratos, if you read this, would you be interested in making a template that entirely complies to accessibility standards, maybe with consultancy from Nils?

Quote:
Form fields
Forms are pretty difficult - at least in the beginning. All forms used within CMSMS that I have seen so far do not conform to WCAG. There are certain tags, such as fieldset, legend and label that must be used. Took me quite a bit to get this working. Especially in modules such as bookmarks, etc.


Yeah, forms both in the admin panel itself and for modules that are outputting forms to the frontend need to be adapted to accessibility standards. Many modules have templates that can be customized from the admin interface. Or for the admin interface itself templates saved in tpl files (like for modules such as News, FeedbackForm, CMSMailer, FCKeditorX, Uploads to mention just a few.).

To change the code for the forms used in these modules' admin interfaces would be quite simple by changing in the templates. That should be part of the principles for module development that there is a thread about in the Modules/Add-ons forum.

Nils, would you want to write some guidelines about accessible forms and how to make an accessible admin interface form, in that thread?

As for Bookmarks, I tried making Bookmarks use these kind of templates and also to localize it to allow for translations. But as programming is not my field I got stuck. Silmarillion will look at it when he gets the time, although he's now also working on Xinha and doing changes to Calendar.

Quote:
WYSIWYG editor
I am still waiting for Xinha to be integrated into CMSMS. Actually most customers are overwhelmed by the possibilities offered in FCK or other editors. So I used widgEditor but this one does not work with CMSMS image manager and link manager. And it did not support use of smarty-tags in the content field. While I got the latter working with lots of efforts, I was not able to integrate image- and link manager. But a good WYSIWYG editor with valid source-output would be really good. When it comes to ATAG later (hopefully) this will be the most crucial point.


There is already a version of Xinha released, but it has been rather much improved since that release (and also requires a change to admin/footer.php that was made after 0.11.2 was released). Silmarillion is doing some great work there!

In the end it will be possible to customize the toolbar, both by enabling/disabling plugins and selecting what buttons should be there. That way the admin can choose to only use the buttons that the users should be able to use. It is my hope that this can also be done for FCKeditorX, instead of disabling buttons in a file.

However, Xinha itself is still in development and there is currently no stable release available. Witha few exceptions it is stable, though, so from 0.12 it can be used by any means. There are also a few accessibility issues that have to be fixed in the Xinha distribution itself, instead of doing hacks to the CMSMS Xinha module that makes it difficult to upgrade the Xinha version used for it.

The ideal WYSIWYG editor for accessibility would otherwise probably be XStandard. But that is available for free in a limited version only, while the full version costs. It is also quite difficult to install and has no image manager, but one has to type the URL to the image, which is quite a hassle. But the XStandard team works purposely to make it output accessbile code and being accessible to use.

There is a CMSMS module for XStandard, but I don't think it works in later versions of CMSMS.

With all that said, I think with FCKeditorX and Xinha fully developed, they will be very useful.

Quote:
Search / Search results
While there was not integrated search I hacked together a script consisting of multiple solutions. The output of search-results therefore was a bit tricky. The user should be able to sort the results according to his / her needs. Couldn't get that working within my projects. However I mangaged to generate an ordered list
    for output. But something more sophisticated for search input and output would be highly recommended.


There will be an integrated Search function with CMSMS 1.0. You could also use Pisearch, which allows you to select the template for the search results, to get it exactly the way you want it.


Quote:
News / Events
Both modules were kind of buggy when I used them. Don't know if the handling is better now. Had to hack my way through the scripts to get rid of
and all kinds of rubbish code in there. Not very semantic. Especially events. Had to recode the list-output so that it renders without tables but with definition lists. The calendar itself should be a data-table and marked-up as such.


For News and Calendar (if that's the module you are referring to) you can create the templates in the admin interface, so you can get exactly the code you want on the page. The default templates could of course be changed to better comply to accessibility standards.

If you mean the admin interface, that too can be altered in the tpl files.

Please post feature requests in the Calendar module project or the CMSMS core project for News!


Quote:
Clean-URLs
One of the things I could not get rid off were messy URLs when using modules. I would highly appreciate a solution for clean URLs - maybe someone comes up with a good idea.


Yeah, that sure would be great. Please also post these kinds of suggestions as Feature Requests, as we go through that list during the development team meetings, to decide on the priorities.


Quote:
Just one wish ...
It would be pretty cool to have Tidy integrated into CMSMS, maybe even within the pre-render process to validate the source, remove unwanted elements and do stuff like that. As far as I'm concerned I know my tools and manage to validate a page. But most end-users of CMSMS don't. And they might need some help.


Another cool idea. I haven't looked at the Code Manglermodule, not sure if that can do any of that. But using HTML Tidy, like the way it is used as an extension to Firefox would be fantastic. Not sure how it would work in practice though. Ideas?


Again, thanks a lot for your feedback, Nils! This helps us improve CMS Made Simple and accessibility is on the agenda, for sure!

;D ;D ;D


Top
  Profile  
 
Share On:
Share on Facebook Share on Twitter Share on Google+
 Post subject: Re: Accessibility issues with code-output
PostPosted: Sat Jan 07, 2006 1:51 pm 
Offline
Power Poster
Power Poster

Joined: Wed Sep 08, 2004 3:32 pm
Posts: 520
Patricia wrote:
Nils, actually if you are talking about the Event module that I made from News code at that time, you must know I made it for a special user request, and didn't plan to release it.


Patricia,

No ... sorry - I am not using the Event module but I kind of abuse the Calendar module for events. So it was my mistake. Westis got it right: It is News and Calendar that I am using but these are quite some old modules:

Calendar 0.6
News 1.7

Regards
Nils


Top
  Profile  
 
Share On:
Share on Facebook Share on Twitter Share on Google+
 Post subject: Re: Accessibility issues with code-output
PostPosted: Sat Jan 07, 2006 2:13 pm 
Offline
Power Poster
Power Poster

Joined: Wed Sep 08, 2004 3:32 pm
Posts: 520
Navigation
Quote:
That's cool. Would you mind sharing how you solved this and other accessibility issues? I'm sure you even could be given access to work towards the core in svn to work on accessibililty issues such as this. I for one would be very happy to see these things implemented in the core. ;D


I will try to zip the files I have modified, but I am not sure if I can remember all of them. And I do warn you: I am no programmer at all so it is all quick and dirty.

Sitemap / Breadcrumb
Quote:
Could you give concrete examples of what fields you would like to be added and how these would alter the code that for example bulletmenu outputs?


Sometimes all I need is a field that I can attach to the content area, like for example to clearly idenify parent categories or a page that I want to hide from "normal" visitors. Then some kind of extra field would be handy ... one that you could assign the name and the value. Let's call it CustomField ... I have seen this in NucleusCMS as a method for meta-tags (title, description and keywords would then be the names of the fields and then you can specify the values on a per-page-basis).

Quote:
Piratos, if you read this, would you be interested in making a template that entirely complies to accessibility standards, maybe with consultancy from Nils?


I am not familiar with pimenu but I could give it a try. As far as I'm concerned I could live with some kind of updated bulletmenu.

Quote:
Nils, would you want to write some guidelines about accessible forms and how to make an accessible admin interface form, in that thread?


Yes, but I am pretty occupied right now. So it might take some time.

Quote:
In the end it will be possible to customize the toolbar, both by enabling/disabling plugins and selecting what buttons should be there. That way the admin can choose to only use the buttons that the users should be able to use. It is my hope that this can also be done for FCKeditorX, instead of disabling buttons in a file.


Good news indeed. I am looking forward to it!

Quote:
The ideal WYSIWYG editor for accessibility would otherwise probably be XStandard. But that is available for free in a limited version only, while the full version costs. It is also quite difficult to install and has no image manager, but one has to type the URL to the image, which is quite a hassle. But the XStandard team works purposely to make it output accessbile code and being accessible to use.


A real good editor, but not the one of choice for me. Might come in handy when we are heading for ATAG (if we ever do).

Search / Search results
Quote:
There will be an integrated Search function with CMSMS 1.0. You could also use Pisearch, which allows you to select the template for the search results, to get it exactly the way you want it.


Yes, already saw that. But back in "the old days", even before pisearch, I had to hack something together ... I will give 1.0 a shot and see what it does.

News / Events
Quote:
For News and Calendar (if that's the module you are referring to) you can create the templates in the admin interface, so you can get exactly the code you want on the page. The default templates could of course be changed to better comply to accessibility standards.


I will need to look at them again as soon as possible. However, I will include my changes in the zip file ... as soon as I am able to recall what I have changed. Maybe I find the old non-modified-files of CMSMS somewhere and run a diff ... that would be easiest then.

Quote:
Please post feature requests in the Calendar module project or the CMSMS core project for News!


Yes, you are right. I should do this ... but I keep forgetting it. Shame on me! :(

Clean-URLs
Quote:
Yeah, that sure would be great. Please also post these kinds of suggestions as Feature Requests, as we go through that list during the development team meetings, to decide on the priorities.


I promise I will post it!

Tidy
Can be run as a cgi-script, as an apache-module or whatever ... should not be too complex to be integrated into CMSMS. At least it was not very complicated to add it to Typo3 back then.

Quote:
Again, thanks a lot for your feedback, Nils! This helps us improve CMS Made Simple and accessibility is on the agenda, for sure!


I will do my very best to be of any help. Since my PHP-coding really sucks that is the least I can do.

Regards
Nils


Top
  Profile  
 
Share On:
Share on Facebook Share on Twitter Share on Google+
 Post subject: Re: Accessibility issues with code-output
PostPosted: Sat Jan 07, 2006 4:11 pm 
Offline
Power Poster
Power Poster

Joined: Sat Sep 10, 2005 4:45 pm
Posts: 650
Location: Växjö, Sweden
Quote:
I will try to zip the files I have modified, but I am not sure if I can remember all of them. And I do warn you: I am no programmer at all so it is all quick and dirty.


That would be cool. All the old files are in svn, so you can run a diff there. Or just use a tool like WinMerge to compare your files with the current ones. Or you can just e-mail the zipped files (or put them here) and I (and others) can compare. :D

Quote:
Sometimes all I need is a field that I can attach to the content area, like for example to clearly idenify parent categories or a page that I want to hide from "normal" visitors. Then some kind of extra field would be handy ... one that you could assign the name and the value. Let's call it CustomField ... I have seen this in NucleusCMS as a method for meta-tags (title, description and keywords would then be the names of the fields and then you can specify the values on a per-page-basis).


Where would these fields add to the html output of the page? And what do you mean by identifying parent categories?

As for hiding some pages from not logged in visitors, you can use the Frontend Users module (downloadable in the forge).

As for adding metadata, in 0.10.X there was a field for head tags (in the Options tab), where you could add description, keywords etc. For some reason that was removed in 0.11.X, where instead one is supposed to add a {content block='headtags'} tag in the section of the template, and then that will appear as a content block when editing a page.

This has eben discussed, however, and most likely future versions will see the return of some kind of head tags box when editing a page. I've suggested that a tag like {metadata} is introduced to be in the template. For each page there should then be fields for title, description, keywords, author etc., that is the metadata tags, that the user just can fill in (without having to enter etc.).

This should also be possible to enter globally, for all pages, somewhere in Site Admin -> Global settings. Then the {metadata} tag in the template grabs the metadata both from the page and those that are on all pages.

Is this what you had in mind, or you were thinking of something else?

Quote:
I am not familiar with pimenu but I could give it a try. As far as I'm concerned I could live with some kind of updated bulletmenu.


Bulletmenu will be templated in CMSMS 1.0, that is code and design separated so that one easily can change the template without having to hack the code. The default template should also be made to comply to accessibility standards. ;D


Quote:
Tidy
Can be run as a cgi-script, as an apache-module or whatever ... should not be too complex to be integrated into CMSMS. At least it was not very complicated to add it to Typo3 back then.


There is a HTML Tidy plugin for Xinha, that can be run for the content that is edited with Xinha. The rest of the code (the template, navigation etc.) should be made accessibility compliant, so that all that would need to use is the content. Not sure if there's something like that also for FCKeditor, although it's said to output XHTML compliant code as is and there are features for pasting from Word, for example, to get rid of the weird attributes that comes with that.

But maybe there can be some kind of HTML Tidy module for the templates and modules too.

Thanks!


Top
  Profile  
 
Share On:
Share on Facebook Share on Twitter Share on Google+
 Post subject: Re: Accessibility issues with code-output
PostPosted: Sun Jan 08, 2006 12:24 pm 
Offline
Power Poster
Power Poster

Joined: Wed Sep 08, 2004 3:32 pm
Posts: 520
Quote:
Where would these fields add to the html output of the page? And what do you mean by identifying parent categories?


I was thinking of something like {customfield} that you could place anywhere in the code. Not only in the header-section (where I could use the current header-tags) but also in the body. With this I one could have css-signatures for the body (if neccessary) like or I could have some custom image inserted if neccessary (and if specified). Right now I have to do this in the template by hardcoding it with smarty.

Quote:
This should also be possible to enter globally, for all pages, somewhere in Site Admin -> Global settings. Then the {metadata} tag in the template grabs the metadata both from the page and those that are on all pages.


I like the idea of {metadata} for the header-section - especially with the possibilities to specify them globally and locally so that the local entries would overwrite the global ones if specified.

Quote:
But maybe there can be some kind of HTML Tidy module for the templates and modules too.


Actually I thought of using Tidy not only in case of WYSIWYG but in general. This is because it features the possibility to examin accessibility issues and have them fixed automatically. Here are some links to tidy-projects:


Hope that helps.

Regars,
Nils


Top
  Profile  
 
Share On:
Share on Facebook Share on Twitter Share on Google+
 Post subject: Re: Accessibility issues with code-output
PostPosted: Sun Jan 08, 2006 3:21 pm 
Offline
Power Poster
Power Poster

Joined: Tue Dec 13, 2005 10:50 pm
Posts: 1408
Location: Finland
Quote:
Actually I thought of using Tidy not only in case of WYSIWYG but in general. This is because it features the possibility to examin accessibility issues and have them fixed automatically. Here are some links to tidy-projects:

    * Tidy
      http://tidy.sourceforge.net/
    * Tidy as Apache module (mod_tidy)
      http://mod-tidy.sourceforge.net/


Hope that helps.


mod-tidy sounds interesting. Im not sure if I understand it right, but one could set tidy be on for a virtualhost and if one has written invalid code, modtidy would complain about it, but if the code is ok it would be shown as it is?

this would save a lot of time when writing pages as there would be no need to validate every page individually.

It cant be used in a production environment though as it is quite cpu intensive and would create extra delay when viewing pages...


Top
  Profile  
 
Share On:
Share on Facebook Share on Twitter Share on Google+
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 9 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
A2 Hosting