break
Apr 18

Typical CMSs have been notoriously not Accessible. This has changed a bit, so here I will be posting some of the more accessible versions of CMSs.

This list will therefore be growing so keep an eye on it.

What is a CMS for? Well anyone can use them, but they are meant for larger complicated sites, or sites with many people accessing them. Say a organization with many offices or departments and each group has their own information areas they update. But also if your customer wishes to care for the site themselves. You spend allot of time making the site accessible and error free, then your customer messes it up some how, then visitors think you messed it up.

Best is to create the site from the ground up within the CMS. However in some you can insert sections of your already made site as well, but that is more troublesome. Another advantage is extensions like search scripts, calendars, guest books etc. that you can add more easily.

Free (mostly GNU license)

  • Typo3 - This is a German CMS, but the main language is English and it supports over 20 languages in the Back end. It is GNU and based on PHP. It is a high end professional CMS with a steep learning curve, but it also has a large support community and lots of good extensions to it. It sells itself as accessible and is one of two CMS suggested by a German Accessibility group.
    [Comments: I spent over a week on this system. It has a steep learning curve. It also uses it’s own language which you need to learn to really work with it. In the end it is to complicated for the simple sites I needed a CMS for. It seems to be a good corporate CMS, but be prepared to learn for quite a while first.]
  • Papoo - Another German CMS (supports English as well) claiming accessibility. This one is rather new so the support community and extensions are not so large yet. The back end is much more simplified and better for private sites and I will be using this one next.
    [Comments: This has a very simple background and is easy enough to set up and the back end is simple. However you really need to use a variation on the Papoo design, I was not able to easily carry my design over into the script so I dropped it as a possibility for my projects.]
  • Plone - this is the second CMS suggested by the German Accessibility group. It is powerful and easily extended to meet your needs. One possible drawback is that it is based on Python which is not as widely supported, so be sure your server supports Python first.
    [Comments: I never really worked with Plone so not much to say. I installed it while not really looking for one. It took over my server so I removed it again. It’s use of Python may hold it back as few people really know the language.]
    [Comments from Stefan Mischook of KillerSites.com: I don’t think Plone would be a good choice for most (though it is powerful,) because it requires massive server resources that most people simply don’t have. This is direct from the Plone website:]
    Plone is much heavier on RAM and CPU usage than your run-off-the-mill web system. It’s built to do a lot of different things, and should preferably be hosted on a dedicated server if possible.
    The most important consideration when building a Plone server is to have enough RAM. To take plone.org as an example, it uses about 500-700MB of RAM fully cached. It is a very busy site, though - so you will get by with less, normally. For basic usage, you can get away with about 100MB RAM usage. You should have at least 512MB RAM
    Considering that standard hosting plans give you between 64 to 128 megs of ram - Plone simply doesn’t fit.]
  • PHP CMS - This is another German system (in English) I am looking at now. Sounds good, but am having a devil of a time with the installation. Sites made with it have tested well for accessibility by a leading German organization (of course a web sites accessibility still depends on the designer)
    [Comments: I never even got this running right on my local server, then when taking a break and trying to blend the template into the frame work….. I gave up. What goes where is not clear to see at all. It may be easier if you have experience with SmartyTemplate which it uses.]
  • CMSimple - this came into a quick consideration as a tool but we never followed up on it, not fitted for our project, but may still be good for you.
  • GreenBeast - (This CMS has been discontinued) by accessibility advocate Mike Cherim. I will be testing this soon, I have never used it but I respect Mike so that goes a ways with me.
  • Textpattern - this was brought up in another forum when discussing CMSs and the poster claimed it is accessible, glancing around the web site it does claim to be standards compliant, I did not specifically see a claim for accessibility, but that does not mean that it is not. It does look interesting and maybe of interest to some of you. It also comes in multiple languages and is said to have a good community behind it, but the documentation is said to leave something to be desired.
  • Joomla! - [Edit: I have heard from a former member of the core group who was heading the accessibility part that he has resigned due to the team’s speaking much and doing little about accessibility. Joomla apparently has shied away from going with accessibility and I can no longer suggest it’s use until a working accessible version is truly released, which would seem to be no time soon]
  • MKDoc - this one doesn’t really even claim to be a CMS, but does much the same. I have no experience with it.
    • Easily manage and deploy content on the internet.
    • Create and manage online communities around your website.
    • Publish materials in multiple languages.
    • Comply with e-gif / section 508 accessibility standards.
  • CMS Made Simple - This is a new one to me. I was suggested in a forum and a member I respect said it looks good but was not fitting his project. It is not claiming to be accessible but would seem to be easily modified. I hope to check it out in the near future.

Shareware

  • QnECMS - This one does cost money. This is a development of GAWDs (Guild of Accessible Web Designers). This would be my No. 1 choice if not for the English Back end.
    [Comments: This is the CMS I have settled for. It uses no Back end, the administration links are hidden and appear at the bottom of the site after you sign in. It is built in the style of a Blog. All articles and pages you create [b]can[/b] be set to allow comments by the user, your choice. Plugins include a newsletter and a Pole. It has a built in RSS feed, all your newest postings to your site are automatically fed into the RSS and your subscribers can follow what has changed. Anyone can join your site and depending on how you set it up create their own pages that naturally will only be posted after you OK them.
    What I had not managed in any other CMS, I carried my template into this CMS in one day and was able to keep the design exactly as I wanted it. You simply copy and paste your HTML sections into a template and upload your CSS. It is not cheap, but the price is in my mind worth it. You can purchase a multiple license, then sell as many as you like or simply build it into your future projects and add it to the project cost, after say a half dozen uses, you have recovered the cost. There is a Demo available at the web site and I will likely allow a Demo from my DarkShadow-Designs when it is finished so you can see how I modified the CMS and blended my Template into it. The multilingual support is being developed and I am doing the German Translation which will be the first offered.]
  • LiveStoryBoard - Subscription. Claims to be Standards compliant. No experience with it, but it is in my Bookmarks so someone must have suggested it to me at some point.
    [Comments: No experience with this system]
  • Libertas-Systems - Offers a CMS, they are members of the Accessify Forum and I know they are interested in accessibility as well.
    [Comments: No experience with this system]
  • Colony CMS - A Standards based Accessible CMS brought to my attention by Richard Conyard who is involved and I know from Accessify as well. Once again someone I know is interested in accessibility.
    [Comments: No experience with this system, Richard Conyard is however a developer I respect.]
  • NQContent - this is new to me. However as you will see reading the main page many UK government councils and some organizations have chosen it for it’s flexibility.
    [Comments: I have no experience on this CMS nor will I due to the Price. You must also expect to re-pay the licensing fee every 1 or 2 years. I have yet to note where it claims accessibility, however many choosing it fall under UK Government Guidelines so it clearly can not be unaccessible and is flexible enough to really tweak it to make it so.]
  • Polopoly - this is a Swedish CMS for larger comapanies and corporations. There is no price to bee found easily when scanning the site but I assume it is not cheap.
    [Comments: No experience with this system. It has a rather impressive customer list. Many which come under the UK’s DDA accessibility law, so it is said to be good as far as accessibility is concerned.]
  • NQcontent - This one makes many claims to accessibility compliance. Again it is a CMS for larger organizations.
    [Comments: No experience with this system]
  • Subdreamer - Not sure who suggested this one, nor do I see any apparent claims to accessibility. However it does look promising and has a price tag a normal person can swallow with a little struggle. Also offers a Photo Gallery ad different skins.
    [Comments: No experience with this system]

I have also come across one named CMSimple.

But keep in mind, a CMS is only a tool to help speed up site creation and maintenance, accessibility is still a matter of common sense, you have to change things by hand still sometimes.

You may also find OpensourceCMS.com useful.

Lastly, Mambo is well known but not an alternative in my mind if you wish accessibility. Although far from the best, if you want Mambo I would at least stress that you consider Drupal as the better of the two.

Blogging

Those of you into blogging have likely heard of WordPress as one of the best programs for it. However be default WordPress is not specifically Accessibility targeted. [There as been a major new release improving Wordpress, 2.2. It is sweet, we are using it at the paper for our blogs. 05/15/07]

A web developer I know and respect has created a WordPress theme that you may find interesting and that will improve the accessibility of your site. Beast-Blog theme for Wordpress.

Since the publishing of this thread in April of 2005, there seems to have been some movement and a few more products have come to light… all of which I have not used. So I offer to you two more links, a piece on CMS accessibility from 456 Berea Street with allot of CMS suggestions in the comments and some CMS Test results from Juicy Studios.

Date April 18th, 2005 Filed in Accessibility, Web Development No Comments »
Apr 18

“You have to use the right tools for the job!” - Bob the Builder

That is one of my battle cries. I once went on a rant, my daughter (5 yrs. at the time) stood by and listened as I went on about misuse of tags to her mother who knows some HTML. Well Jessie looked at me and said “You have to use the right tools for the job! Right Dad?”, you can tell she was a big “Bob” fan.

But it is the truth for web design too. Accessibility is supported by little things like logic and standards. Most all out tags have a meaning, this meaning is often a specific action in a browser or screen reader. So by using the wrong tag for the job you disturb the logic and semantics of the site and make it harder to use.

Again I will be adding to this as time goes on, so keep checking back, I may have learned something new or remembered something.

HTML Attributes: The W3C has pretty well done away with many HTML Attributes like background colors ad borders etc. All formatting should be done using CSS. This allows you freedom for doing more things like dotted borders that HTML does not allow, you can change something site wide quickly and easily. You make your pages smaller and faster.

H1 - H6: These have a meaning, they are headers, like chapters and sub chapters in a book. They do not exist so you can have a bold text of a certain size. They tell the user agent that all text following this word are under it in the scheme of things. This word hints at what the following text is about.

So logical markup of the page makes the site more usable and accessible to everyone. If a word or phrase describes the following text, then use a header and not just bold text tells a non-visual surfer nothing.

Also it has a logical order, H1, h2, H3… do not use H4 in the middle of a page because it is the size you are looking for! Use CSS to make the correct header the size you want! Also you should never have a H3 without a H2 preceding it before H1. According to the specs you can in fact start with a H3 tag for instance as long as no earlier tags are used. So you can mark up with H3, H4, H5 & H6… the question is why would you want to? There is no logical reason to start with anything other than an H1.

Now it is sometimes argued whether a page should have 1 or multiple H1’s, this is not provable either way. Tendency seems to suggest most developers feel each page should have only 1 H1 that describes the page. Under it you can then have multiple H2 with multiple H3… as you need.

Others argue that content can/should have a H1, but Navigation is a separate area, so can/should have a H1 as well. These are reasonable arguments so the battle rages on. I prefer single H1 describing the page.

Also it is rated high with Search Engines when the best Keywords are included with the page title and the H1, it increases the ranking. Often my H1 matches my Page title, but that is not required.

Just remember to use headers in a logical manner where and in the order the are meant to be used and format them with CSS.

<I><B> vs. <Em><Strong>: Here you will hear many argue not to use I and B any more as they are depreciated. More correctly, use them right. I & B are both visual tags. They are of no use to blind users to highlight important text.

So if you wish to highlight a word and say that this word or phrase is more important then the rest, use either <em> (emphatic) or <strong>, this reacts with a screen reader and this word sticks out audibly from the rest.

Now some argue that <em>, which is usually visually italic, is harder to read for those with poor vision, so it should not be used often and mostly one should use <strong> which is shown bold.

If you wish to highlight words for some reason (studies show that when a first paragraph is shown bold it gets more attention from the reader) but that word is not more important, so you wish it to be only visually bold, then it is fine to use <b> instead, as a extra emphasis to a word with no real meaning could be confusing as well.

<Blockquote>: one of the most misused tags I see. Often used for formatting. Again it has a meaning to a screen reader, it says “the following long block of text is a quote” and is confusing if it is not a obvious quote. It is also used together with the cite attribute <blockquote cite=""> with a reference URL to whatever web site is being quoted from. Again you can/should format it with CSS. However the cite attribute has never been supported by user agents and so the info is not easily available to the user unless they look in the source code.

<Q> & <blockquote> it should be noted are per standards required to insert the needed ” quotation marks. That is to say we should simply write <q>bla bla bla</q> and the browser would add “bla bla bla”. But as usual this is definitely a no go in IE (IE 7 and below for now), so if you use the <q> element, a standards browser should install the “” for you, but IE will not and the text will not stick out. If you insert the “” for IE a standards browser will show “”bla bla bla”". That is why many developers simply use “”in the code rather than the quote element. Firefox, Safari and Opera will show quotes in the fist and double quotes in the second example. IE will show no quotes and single quotes.

Example 1: I have added no quotes, standards compliant browsers will show quotes, IE will shown none.

“Example 2: I have added quotes, standards compliant browsers will show double quotes, IE will shown single.”

<Cite>: the cite tag would seem to be just another version of quote, but it is meant to be used with the quote tag. Cite is literally the credit to the person being quoted:
As <cite>Harry S. Truman</cite> said,
<q lang="en-us">The buck stops here.</q>

Lists: Also commonly not used correctly. best example is a Navigation bar. What is it? A list of links right? So why not use the list item? It is logical right?

Well usually it is not use due to the bullets, but now with CSS those can be removed and the list laid out horizontally. It also makes formatting rollovers etc much easier by defining the <ul> and <li> rather than having to use classes.

As for which list to use, for purity, most would say that an ordered list is correct as it numbers the links in order of priority. others argue that the order you choose to place your links implies priority and therefore an unordered list is fine. It really does not matter, but unordered lists are more common.

Also do not forget Definition Lists. These are a list of Definition terms (DT) and definition definitions (DD). The DD defines the DT. Clear use would be for instance a glossary of terms. However it can be effectively used as a format for sitemaps, The site page name would be the DT, and a page description is the DD. I have written about this in more detail in my: Lists, more than just Bullets

So use lists where you need them, it makes the site logical and more attractive to search engines.

<P>: I should not have to even mention this, but even today you will still find people writing text in a DIV for instance and using multiple &lt;BR&gt; tags to space them. Why? I have no idea, it is beyond me. So just use the Paragraph tag as that tells the user agent that it is in fact a Paragraph… logical.

<BR>: There is a use for this and it is not making space. There are times when you want to manually break a line at a specific place. A good example of it’s use would be lines of a poem that need to be broken at specific points. There is some discussion as to whether BR is a visual tag or not, I believe it is not, the effect it has breaking lines is visual, but the tag itself should not be considered visual.

<Address>: I have dedicated a separate post to another misused tag, the <address> tag and it can be read at: Fun house mirrors and the Address tag.

<Code>: is a tag meant for code clearly. The problem with this tag is that it ignores white space and brackets, anything you use code wise will be read as source code, so you must break it out by coding the brackets with &lt; & &gt; so it is not read as source code. For minor work this is fine. But when you wish to use more complicated code or scripts? Then you can embed the code in <pre> tags and embed that then in code tags. This way it is still recognized as code.

<Pre>: protects white space. It means preformated and results in a ticker type type of font and all white space like indentions are protected so the code still makes sense. Semantically it makes sense as it simply days this text is preformated in a manner the author chose and when embedded within the Code tags it says that text is code.

Date April 18th, 2005 Filed in Accessibility, Web Development No Comments »
Apr 15

One of the most important cornerstones to Accessibility is using W3C Standards. That means you need to understand them as well. No small feet.

Clearly the first stop is the W3C (World Wide Web Consortium) itself.

So what language to use? Short answer, whichever you prefer, but here is what you should consider. Below you will find some good links on these subjects.

HTML

Html is still a Standard and the newest version of HTML available. Some still believe that XHTML replaced HTML (something I believed until 2003 as well) and HTML is retired. Wrong!

HTML 4.1 and XHTML 1.0 were both released in 1999 and are equal standards, neither better or worse than the other. HTML is fine to use and no reason not to.

What I would [b]strongly[/b] suggest is that you however serve it with the Strict DOCTYPE. That is how it is meant to be served, that is pure HTML as it is meant to be written. But more on Strict and Transitional another time.

Also I strongly suggest you write HTML as close to XHTML as you can to get into the habit. This means always write in lower case, never should any element, attribute or name ever start with a capital letter, that should be avoided. Also be sure to wrap all attributes in “”, so rather than Border=1, write border=”1″.

XHTML

XHTML is falsely understood by many to be a later version of HTML that looks a little like XML (Extensible Markup Language). Wrong!

XHTML is a XML Language that is formatted to look like HTML. But being XML it requires lower case names and all tags must be closed including empty tags like <br/> <meta …../> <img …. />.

Now it gets complicated.

XHTML 1.0 - A very morphed version. It was created to “Help” us get used to XHTML ad XML. But it is very backwards compatible. It even carried forward that bad W3C habit of Frame, Transitional and Strict DOCTYPES. It is a very lax language you can even serve as HTML.

XHTML 1.1 - A step to real XHTML, very modulerized. No longer has Transitional, Frame and Srict DOCTYPE, it is simply strict. It must be served as application/xhtml+xml.

XHTML 2.0 - Not released yet, this is not compatible with HTML at all. Must be served as application/xhtml+xmll.

Also such JavaScript such as document.write() will not work in XHTML served as XML, you will have to learn to create JavaScript with the DOM (Document Object Model).

You will also no longer be able to hide CSS in your pages as the SGML style comments no longer work (<!–   –>), nor can you use inline styles anymore. So all CSS must be in either external sheets or in the head using <![CDATA[ ????? ]]>, this is more trouble then likely worth it so best to simply use external style sheets.

So that brings me to TagSoup.
Tag Soup is serving XHTML as HTML. You see when a page is requested it goes to a server with a “Header” that explains what language it accepts. HTML is served as text/html.

Now when I write a simple XHTML page, it is still being served as text/html. It is written as XHTML but served as poorly written HTML. This works with XHTML 1.0 but not the others.

The problem comes with serving XHTML correctly as XML. IE does not understand that and tries to download the page! So to work in IE you have to use “Content negotiation”. For instance a PHP script that says if it accepts application/xhtml+xml, if not it serves it to IE as text/html.

Also when served as XML, you can no longer use such things as <!–   –> for comments as that is HTML and not XML. I you use XML comments and serve it as HTML, those comments will show.

So at this point XHTML is not truly supported. You can write XHTML but by serving it as HTML you loose all advantages like working with MathML or SVG.

So when it is all accounted for, the trouble of working with correctly served XHTML with todays browsers…. it is not really worth it.

If you are just doing a simple site with no need for SVG or MathML and such things, then it is fine and easier to use HTML, just do it Strict as it was meant to be used and keep coding as close to XHTML as you can with lower case and “” wrapped attributes.

For more on this subject, or as proof that this is not something I dreamed up when bored, here are some handy links on the subject:

Date April 15th, 2005 Filed in Web Development No Comments »