Thanks a lot, Nils! This is the kind of feedback that we need to make CMSMS comply to accessibility standards!
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.
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?
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.
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.
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.
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!
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.
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!