'

[Irl-dean] Accessible CMS

Laurence Veale laurence.veale at iqcontent.com
Thu Dec 7 15:15:55 GMT 2006


Hi Eamon,

It was great to get to talk to you at the IrlDean conference yesterday.

Josh has done a great bit of work in comparing the open source offerings.
However, as we discussed yesterday, one thing to watch out for with open
source solutions is the total cost of ownership. For example, what level of
support do you need, who do you ring when you've got a problem, who can fix
it, are you tied to whoever customised the open source solution for you?

Just some food for thought,

Laurence


On 12/7/06, Joshue O Connor <joshue.oconnor at ncbi.ie> wrote:
>
> Hi Eamon,
>
> >> I would like to ask the list if they have any thoughts/experiences on
> >> accessibility of Content Management Systems (CMSes).
>
> This is an area that CFIT have been looking at over the last year. I put
> my findings together and wrote a paper that, was accepted by AXMEDIS
> (http://www.axmedis.org/axmedis2006/ but myself and Gez are presenting
> another paper there next week,  so I don't think I will be presenting
> this one. The paper is in a kind of limbo at the moment looking for a
> home, so in the spirit of sharing here it is. I hope you find it useful.
>
> Feel free to use it as you will, and if you do please just give CFIT a
> nod.
>
> Josh
>
>
> CHOOSING AN ACCESSIBLE CMS
>
> Joshue O Connor
> Senior Accessibility Consultant
>
> Expert Screen Reader Evaluation
> by Paul Traynor CFIT
> NCBI CFIT
> joshue.oconnor at cfit.ie
>
>
> Abstract
>
> How do you go about choosing an accessible content management system
> (CMS)? What are the main criteria for success? And how to ensure ease of
> use for authors including screen reader users?
>
> CFIT looked at several popular CMSs in order to assess which would be
> most suitable. The successful CMS had to be capable of outputting
> standards compliant markup and have an accessible user interface. Other
> factors such as the overall ease of use and usability were considered.
> It was also necessary for the system to be feature rich and scalable.
>
> Our approach was to look at how these CMSs work "out of the box" and no
> complex heuristics were applied in order to simulate how many other
> users would approach the adoption of a CMS in the "real world". The
> assessment method was an intuitive approach with some basic core tasks
> such as adding content and administration.
>
> 1. Introduction
>
> There are many commercial and open source CMSs available today and
> making the right choice can be very daunting.
>
> Some factors to consider are the technical skill of the staff who will
> use it and the behind the scenes work needed to set up and customise the
> system. The amount of time it can take to properly check the viability
> of a CMS is itself something that can put many off choosing and
> implementing a reasonable open source system, so many will go to
> companies who offer a commercial package they have themselves developed
> and offer to take care of the content migration and customisation. For
> those with a large budget this may be a viable solution, but for
> community based groups, disability advocate groups and others with
> little or no budget, are there systems available that can make setting
> up and administration a plausible option with a nominal amount of
> technical knowledge needed?
>
> For the purpose of this paper we are going to look at some popular and
> free CMS packages that could suit the needs of groups like these. Aside
> from basic set up and any related costs including hosting, etc., we need
> to consider if the successful system will be capable of outputting
> standards compliant [1] and valid code [2]. This whole exercise can be a
> daunting task for people who are not technically minded. Many may not
> even be aware that there are efforts to ensure that accessibility is
> already considered and, where possible, built into the CMS. This "under
> the hood" accessibility is courtesy of the Authoring Tool Accessibility
> Guidelines (ATAG) [3]. These guidelines are there to help CMS developers
> create tools that have a user interface that is accessible, as well as
> outputting accessible content. The guidelines aid the developer who
> builds the system to take care of any automatic processes and to
> intervene if some input is needed from the user in order to improve or
> enhance the accessibility of the content. However, there is also a
> responsibility on the part of content authors to ensure that they are
> endeavouring to create good accessible content. There may be an
> unrealistic expectation that whatever the author throws at the system
> will be magically transformed.
>
> 2. What are the main criteria for success?
>
> Our goals were to find:
>
> 1. A CMS which is functional, accessible and usable to authors who have
> basic IT skill level and knowledge of using word processors, but no
> fluency with markup languages like HTML.
>
> 2. A CMS that can be recommend and promoted as an accessible Web content
> management solution for community/disability groups, charities and
> others with a limited budget.
>
> 3. If possible, the WSYWIG editor should be accessible to screen reader
> users. The usability of the mechanism is also important, so we are not
> merely considering if it is technically accessible but also if it is
> easy and pleasant to use.
>
> 2.1 How to ensure ease of use for authors including screen reader users?
>
> All the CMSs that we examined were tested by an experienced screen
> reader user with a strong technical background. He is a power user with
> many years of experience using various screen readers such as JAWS and
> Window Eyes. The CMSs were evaluated in a critical manner with attention
> to the quality of the markup and the finer touches and details that can
> be employed by developers to enhance the user experience for blind people.
>
> CFIT pay particular attention to usability in our testing of any ICT. We
> are not interested in merely "ticking the boxes" or "minimal compliance"
> but in a pleasant and rich user experience that facilitates better
> interaction, whether the user is creating content or administrating the
> CMS.
>
> 2.2 How accessible and usable are some of the more popular open source
> CMSs?
>
> 2.2.1 Methodology
>
> In order to give these tests a real world flavour and to ensure they
> were ecologically valid, we consciously did not use any particular
> testing method or script in order to access how intuitive these systems
> are out of the box.
>
> For the tests we looked at:
>
> •       Jadu
> •       Mambo
> •       Joomla
> •       Quick and Easy
> •       Expression Engine
> •       Plone
> •       Drupal
> •       Textpattern
> •       Xoops
> •       Typo3
>
> 3. Results
>
> Our feedback derives from user testing and observation of a screen
> reader user performing the following basic tasks, as well as the same
> tasks being performed by a user with no Assistive Technology/Special
> User Agent requirements and with an average computer skill level.
>
> These tests were facilitated and observed by an experienced CFIT
> accessibility consultant.
>
> The tasks included:
>
> •       Uploading content and, where possible, editing and formatting
> content
> (using a WYSIWYG editor).
> •       Creating new pages (Category/Section headings and sub
> categories/headings).
> •       Basic administration of user groups and permissions.
>
> For testing the WYSIWYG editors we used a similar methodology to Peter
> Krantz of Standards Schmandards [4].
>
> These tasks were performed for all of the CMSs that we tested. The
> results are not conclusive and are included here to be indicative of our
> experience and subjective assessment of the pros and cons of using each
> CMS.
>
> 3.1 Jadu
>
> Before we started looking at Jadu, we contacted the developers to ask
> about the accessibility of their CMS. They replied, pointing out their
> "use of AJAX and JavaScript in the editor that would make for 'issues'
> with our screen reader".
>
> As a result we did not continue with our screen reader test. However we
> noted that the system has an option to display content as high
> contrast/text only, which many visually impaired users will find useful.
>
> The developers then stated that they have plans to introduce an
> accessible user interface in forthcoming releases.
>
> 3.2 Mambo
>
> Visually, the graphic style of the interface was pleasant to work with
> and the style of the Windows operating systems graphics would no doubt
> be appealing to many users and would not be too much of a departure from
> what they are used to, so this could be an advantage.
>
> From the perspective of "instant usability", our first impression of
> Mambo was quite good, but on starting to perform the tasks we found it
> difficult to then find the uploaded content.
>
> Mambo has a peculiar method of structuring its content with a curious
> mix of sections/categories that we found to be confusing, but once the
> user had familiarized themselves with the way the system works then it
> could be comfortably used.
>
> However, using Mambo was found to be difficult for a screen reader user
> so we could not confidently recommend Mambo as a usable and accessible
> CMS.
>
> 3.3 Expression Engine
>
> Expression Engine is a blog focused CMS which lacks more advanced
> functionality.
>
> From a screen reader users perspective it was frustrating to use. There
> were no structural headings and the blog feature was very difficult to
> navigate and figure out. Title and edit boxes were not marked up well
> and our tester found it unintuitive.
>
> From a usability perspective our first impression is quite good and we
> liked the interface. It is visually quite smart and we found it quite
> intuitive to use. Adding posts is very easy as is creating links. It
> automatically asks for additional information, such as the title
> attribute, when creating a link. Creating a link is a matter of
> selecting your desired link text and then clicking the link button.
> These additional options pop up then.
>
> Module installation is straightforward and there are an extensive list
> of utilities such as an SQL and Plug-in Manager.
>
> However, as it is inaccessible we will not recommend it.
>
> 3.4 Textpattern
>
> Textpattern is primarily a blogging tool rather than a CMS, and a big
> downside to this application is the inability to have more than one
> level in the navigational hierarchy. Our testing with a screen reader
> revealed similar results to Expression.
>
> However, it has a very simple interface and textile text formatting
> system.
>
> Textile is a way of formatting text without using a WYSIWYG editor
>
> 3.5 Joomla
>
> Joomla is a new version of Mambo and it has made some great improvements
> in its overall accessibility.
>
> For a screen reader user, we found it to read very well with JAWS and
> Window Eyes, with no focus problems and no mixing up of lists or combo
> boxes, etc. In our testing it was found to be "Easy to understand, and
> enjoyable to use".
>
> Some more specific positive observations were:
>
> 1. All checkboxes were found to be well labelled and read correctly
> using Window Eyes, JAWS and both Firefox and IE6. Various menu settings
> such as user menu, main menu, etc. were checked.
>
> 2. The log in boxes are fine, no problems with them.
>
> Some problems encountered were:
>
> 3.Some links reading "On Mouse Over" could not be activated by pressing
> the Enter key.
>
> 4. Various items had checkboxes, etc. that weren't very intuitive. The
> labels didn't convey their purpose effectively to the screen reader user.
>
> 5. Radio buttons read well but their labelling could be improved. They
> often were not understandable as to what purpose they served.
>
> If these problems could be addressed, we would recommend Joomla.
>
> 3.6 Quick and Easy
>
> We very much liked Quick and Easy. Some feedback from screen reader
> testing is as follows:
>
> 1. Very simple interface.
>
> 2. Easy to get around and not cluttered.
>
> 3. All items were well labelled and easy to understand as to their
> purpose.
>
> 4. Quick and Easy is made for a user who wants simplicity and a quick
> way to update web content.
>
> 5. I enjoyed my experience of using Quick and Easy.
>
> 6. All lists, list boxes, combo list boxes edit boxes read well with
> both JAWS and Window Eyes.
>
> 7. I noticed that none of the various elements read incorrectly with
> either screen reader.
>
> Quick and Easy is a low cost commercial product and could be suitable to
> a wide variety of community based groups. The administration interface
> is accessible and standards compliant. There is a user determined choice
> of HTML tool, so different people managing the same site can choose
> whatever suits them. Quick and Easy has some advanced functionality,
> such as built in blog, a mailing list application and a photo gallery
> plug-in, but may not be as extendable as some other open source CMSs
> such as Plone or Drupal. However, we do feel it was one of the best we
> tested.
>
>
> 3.7 Plone
>
> From a usability perspective our first impression of Plone was that it
> is not that intuitive. This is primarily down to the labels and page
> types but this could be improved, as Plone is highly customisable. It is
> very feature rich out of the box and this may be why it feels rather
> unwieldy and a little intimidating.
>
> From a screen reader users perspective, we did find the following
> positive points, in no particular order of importance:
>
> •       Skip to content/Skip navigation links.
> •       Good heading structure.
> •       No Frames.
> •       Form elements are well marked up.
>
> The negative points are:
>
> 1. Overall lack of consistency between what elements are visible when in
> forms mode/virtual PC mode.
>
> 2. The naming conventions for items used in the interface are a little
> unintuitive. Use of terms like "Smart Folder" wasn't great, and we had
> no idea what a "Smart Folder" does. However, reading the manual would no
> doubt shed some light on this, which as previously stated, we have not
> done for this test in order to assess the CMS's level of 'instant
> usability'.
>
> When we tried to add a page we found two frames not correctly or not
> clearly labelled.
>
> We also noted some peculiar (and inconsistent) behaviour when using JAWS
> 5. Pressing the F key (or tab key) should allow the user pick out
> elements such as buttons, edit boxes, list boxes, etc. and this worked
> fine. However, when using the arrow keys to navigate through these
> elements, no associated labels or identifying information were read out.
> Now we have to again test this with JAWS 7 and also other screen
> readers, such as Window Eyes, to see if this observed behaviour is
> consistent or something peculiar to JAWS 5.
>
> Overall, Plone was a good CMS and highly customisable and extendable. We
> would recommend it.
>
>
> 3.8 Xoops
>
> Xoops has turned out to be a favourite during our tests with our screen
> reader user who was very pleased with it. He found it easy to use,
> understandable and enjoyable. Form elements are well labelled and the
> layout is simple and uncluttered.
>
> However, from a usability perspective we did not like Xoops. We found
> the interface unintuitive and bare and we just did not like the feel of
> the application.
>
> 3.9 Drupal
>
> In terms of the interface "out of the box", Drupal takes the opposite
> approach to Plone. The interface is simple uncluttered and clean. They
> adopt a modular approach which allows you to customise Drupal so it fits
> your requirements, adding other modules such as a blog, etc. as you need
> to, and thereby presenting the user with a simple to understand and easy
> to navigate interface, which does not overload the user when they first
> open the application.
>
> Drupal is well laid out, with good headings/structure. Access controls
> and checkboxes are marked up well.
>
> It could however be improved. For example the labelling of checkboxes in
> the blog administration page is not very good. There are checkboxes that
> allow the administrator to set permissions for anonymous and
> authenticated users that are also not labelled very well. This makes it
> difficult for a screen reader user to administer the site well as they
> cannot associate each checkbox with its relevant command.
>
> However, these are our first impressions and we feel that Drupal is one
> of the best that we have come across and would recommend it with some
> customisation.
>
> 3.10 Typo3
>
> Typo3 has a confusing interface. It uses a tree structure but the
> interface is inconsistent. The language used is also very "technical",
> which would put off novice users. It uses inaccessible language for
> buttons/commands like "Reload the tree from the server". Even adding a
> page/content is difficult with more unusable tech speak like "the page
> module is activated from the backend menu" being used.
>
> Typo3 also uses frames that are not correctly labelled (if at all) and
> there is a lack of simple heading structure.
>
> There are however edit boxes/buttons with are labelled well but there
> are also peculiar behaviours. For example, when jumping across links our
> screen reader user found that he was also jumping through unidentified
> frames.
>
> We cannot therefore recommend Typo3.
>
> 4. Plone and Drupal Advanced Features comparison
>
> With both Drupal and Plone all of these feature are available either out
> of the box or as a module plug-in*.
>
> Implementation & Setup
> Custom Content Types / Templates
> Workflows/permissions
> Pod casting
> RSS syndication
> XML syndication
> Blogs
> Content Reuse
> Friendly URLs
> Support for Multiple file formats
> Publication Scheduling
> Content Versioning
> Granular Privileges
> LDAP Authentication
> XHTML web output
>
> *However, XML syndication and Publication Scheduling may require
> substantially more development time in Drupal. Also Plone is written in
> Python, which may be an issue for those without skills in that language.
>
> 5. Modifying the Interface
>
> The interface for each system is XHTML / CSS based so each can be
> enhanced and improved. Quick and Easy, Joomla, Plone or Drupal would
> satisfy the website requirements of many community based authors and
> groups. However, the Drupal and Quick and Easy interface, without
> modification, are more screen reader friendly than Plone. Drupal and
> Quick and Easy have a clean and simple UI that will be a help to
> (non-technical) content creators.
>
> Plone has more features available out of the box but many of these
> features may not be needed.
>
> 6. Accessible WYSIWYG Editors
>
> CFIT have concerns about the general accessibility of WYSIWYG editors.
> The two editors we looked at are XStandard and TINY MCE. While using
> XStandard we encountered some problems. The screen reader could not
> properly interact with it and it seemed to leave the user hanging
> without any real idea where he was within it.
>
> It also needs to be keyboard accessible. We contacted the XStandard
> development team and they have produced a Mac version that is keyboard
> accessible, which we have not yet tested. They also mentioned that they
> are currently working on a keyboard accessible Windows version of the
> editor and hope to have it out by the end of 2006.
>
> We found Tiny MCE to be "somewhat" accessible but we have concerns about
> the quality of output; structure is often not maintained.
>
>
> 7. Practical Alternatives to using the embedded WYSIWYG Editors
>
> Use an editor with an accessible interface such as the freeware editor
> PSPPad [5] or the W3C's editor/browser Amaya [6], to pre-format any
> code. The screen reader user can them upload the structured content via
> the CMS. The drawback is the learning curve required on the part of the
> user but it seems to be the most viable option at the moment.
>
> For more on comparisons of editors Peter Krantz of Standards Schmandards
> has done some more extensive testing of a wide variety of CMSs [7].
>
> When embedded WYSIWYG editors improve the accessibility of their
> interfaces this will have a major positive impact on the overall
> accessibility and enhanced usability of a CMS.
>
> 8. References
>
> [1]http://www.w3.org/QA/2002/04/Web-Quality
>
> [2]http://www.w3.org/WAI/GL/2005/06/validity-accessibility.html
>
> [3]http://www.w3.org/TR/ATAG20/
>
> [4]http://www.standards-schmandards.com/exhibits/wysiwyg/sampledoc.htm
>
> [5]http://www.pspad.com/
>
> [6]http://www.w3.org/Amaya/
>
> [7]http://www.standards-
> schmandards.com/index.php?2006/03/03/36-wysiwyg-editor-test
>
>
> ********************************************************************
>
> NOTICE: The information contained in this email and any attachments
> is confidential and may be privileged.  If you are not the intended
> recipient you should not use, disclose, distribute or copy any of
> the content of it or of any attachment; you are requested to notify
> the sender immediately of your receipt of the email and then to
> delete it and any attachments from your system.
>
> NCBI endeavours to ensure that emails and any attachments generated
> by its staff are free from viruses or other contaminants.  However,
> it cannot accept any responsibility for any such which are
> transmitted.  We therefore recommend you scan all attachments.
>
> Please note that the statements and views expressed in this email
> and any attachments are those of the author and do not necessarily
> represent the views of NCBI
>
>
> ********************************************************************
>
>
>
>
> _______________________________________________
> Irl-dean mailing list
> Irl-dean at list.eeng.dcu.ie
> http://list.eeng.dcu.ie/mailman/listinfo/irl-dean
>



-- 
Laurence Veale
Senior Analyst
iQ Content Ltd

Usability | Accessibility | Training | Search

iQ Content is a Google Enterprise Partner

Blog: www.iqcontent.com/blog
Tel: (office) +353 1 817 0768
Tel: (mobile) +353 87 900 2999
Fax: +353 1 817 0769
Email: laurence.veale at iqcontent.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.universaldesign.ie/pipermail/ceud-ict/attachments/20061207/4bbb4dc8/attachment.html 


More information about the CEUD-ICT mailing list