Web Accessibility and Content Management Systems

Abstract

Web accessibility is an issue that is being spoken about more and more, yet very few Free Open Source Software (FOSS) Content Management Systems (CMS) are truly accessible. A growing number of countries are adopting legislation and regulations requiring a variety of websites to be accessible. Further, commercial interests suggest that a website that is fully accessible and usable by all visitors would increase revenues. This paper will review the basic concepts of web accessibility and discuss the challenges of implementing accessibility into existing CMS, using Mambo CMS as a case study.

Introduction

There are dozens upon dozens of Free Open Source Software (FOSS, or OS) Content Management Systems (CMS). Hundreds of them! In fact, The CMS Matrix, a community site to rate and evaluate CMS, lists 959 OS CMS for comparison as of September 2008. There is something for almost everyone.

Whilst we have not conducted a systematic analysis of the accessibility of these hundred of CMS, we have developed websites with many of the bigger names in the CMS "game" – Mambo, Drupal, WordPress, Typo3, Movable Type, Xoops, Xaraya, Plume, e107, PHP Nuke, Joomla!, PostNuke, B2Evolution, Plone, and several more. Each CMS has its strengths and weaknesses, yet the majority fail miserably when comes the time to allow site owners to offer accessible websites to their visitors. The failure is even more dismal when the CMS are tested for accessibility of their administrative interface.

Mambo undertook the journey towards improved accessibility. It has been a slow, yet enriching experience.

The Mambo team has learned about the basics of accessibility. What is it, really? Who does it affect? Is it only for blind people? Why should we, as software developers, care? Is it really the law for people to produce accessible websites? And how does that affect us, since we are not producing websites, we are producing software to produce websites.

The Mambo team also learned about the different sets of guidelines helping developers along the path to barrier removal. WCAG, ATAG, ARIA, these acronyms seemed daunting and obscure at best. The situation did not improve when we actually looked at the guidelines! But we learned about the differences between accessibility for the front-end and the back-end.

Along the way we met many challenges – old code, lack of technical know-how, or implementation issues. We also had to make tough decisions – how much accessibility are we incorporating? How much backward compatibility do we want to preserve? Finally, we reconfirmed the fact that we must inform 3rd Party Developers and users of what we are doing, and provide them assistance so they may transition towards greater accessibility with us, and with a minimum of trauma.

Accessibility Basics

We could not discuss Web Accessibility and CMS without talking about Accessibility. Just what *is* Accessibility? Who is it for? Is it the law? And why should we care? We must have a modicum of understanding of these topics if we are to hope to manage incorporating Accessibility in our CMS.

What Is Accessibility?

The word ‘accessibility’ in and of itself is in fact quite vague. It could refer to a how friendly a building is to wheelchair users. It could relate to how easy it is for anyone to get to a particular building. It could also be the ability of non-US web users to access US-based sites, such as ABC.com which does not provide access to its online video to non-US IP addresses. We tend to assume that everyone knows what the word ‘accessibility’ means.

For the purpose of this paper and presentation, we will be using the word ‘accessibility’ as shorthand for ‘web accessibility’.

Web accessibility means that people with disabilities can use the Web . For a CMS, we must also consider the ability to add and maintain content, as well as site maintenance.

Who Is Web Accessibility For?

The obvious answer to the question "Who is accessibility for?" is "People with Disabilities". Yes, but… What kind of disabilities, exactly? And is it solely for people with disabilities? The following table lists some impairment types (disability types) and some of the many barriers that may be encountered on a site.

Impairment type Barrier(s)
Visual Images, forms, complex tables, pop-up windows,
Hearing Audio only objects (podcasts), Videos without captions, etc
Physical Keyboard only navigation, small link areas, etc
Sensory (epilepsy) Flashing elements trigger seizures
Learning disabilities Complex or "busy" presentation, writing levels, forms

However, there are many other people facing similar barriers that may benefit from the implementation of accessibility on your website:

Legal Environment

Many accessibility advocates keep saying that websites have to be accessible because "it’s the law". Well, is it? The answer is far from clear cut. Please bear in mind that I am not an attorney and only provide my understanding of the situation. Please refer to a lawyer for actual legal advice on these matters.

More and more countries are adopting online accessibility regulations. The World Wide Web Consortium (W3C) lists 20 countries with legislation or regulation pertaining to web accessibility, including: Australia, New Zealand, the United States, the United Kingdom, Italy, Canada, Germany, etc.

The various laws and regulations applicability may be quite confusing. For example, in the United States, there is Section 508 of the US Vocational Rehabilitation Act 1974 (referred to as §508). §508 directly applies only to US Federal organisations and those primarily funded by US Federal funds. An American non-governmental company may think they don’t have to adhere to §508, and infer that their website doesn’t have to be accessible. They could be wrong. While the Americans with Disabilities Act (ADA) does not specifically mention websites and electronic information, it offers people with disabilities protection from disability-based discrimination. Recently Target settled a class action lawsuit against their website. Target is a large chain of department stores operating primarily in the United States. The suit claimed that Target’s website was not accessible.

Closer to us, Australia saw the first major legal decision against an organisation when the Sydney 2000 Olympics’ website was found to be unusable and had to be rebuilt post-haste.

Keep in mind that even if your website is based in Country A, with servers in Country B, if you provide services or sell products online, you are effectively having "the world" as your potential customers. As a result, you may have to adhere to the accessibility requirements of Countries C, D, E, etc!

Why Should We Care? (or The Benefits Of Web Accessibility)

An accessible website is likely to allow more people to visit and use your site, services or CMS. There is an average of 20% of people with disabilities according to census from Canada, the United States, Australia, New Zealand and the UK. While not all these individuals may require accessibility on the site they visit, many do. Many people with disabilities often prefer to do business with a well constructed website rather than go out in "the world" where physical barriers abound.

As mentioned earlier in this paper, there are often legal requirements. As a CMS developer, we may be tempted to think that it is "not our problem" if someone builds a non-accessible site because our CMS doesn’t allow them to. After all, they would be at fault and the ones to be sued. But consider that in lawsuits for building inaccessibility, often the architects, builders and contractors are named in the lawsuit as well as the building owners. It is not far-fetched to imagine that a lawsuit might name the CMS’ developers!

Also, considering that the accessibility requirements of many countries apply to governmental organisations and educational organisations, a CMS that does not provide accessibility cuts out a large part of its potential market.

Finally, it is the right thing to do. We are seeing more and more corporations take social and environmental responsibilities more seriously. Ensuring that hundreds of thousands of people can use the web certainly goes a long way towards social responsibility.

Accessibility Guidelines Concerning CMS

We’ve had a quick overview of what accessibility is, who is impacted by lack of accessibility, and how we can benefit from increasing accessibility. But that remains a bit vague. What areas, specifically, need to be looked at to ensure accessibility?

Each CMS has different functionality and handles processes differently. As such, it would be impossible to give a bullet-proof detailed recipe for making a CMS accessible. That said, there are a number of guidelines offered by the W3C that developers can use. The three main standards apply to three main areas commonly found in CMS

Front-end

This is the "website", what most visitors get to see. It is arguably the most important area of the site to cater for in terms of accessibility. Many CMS allow most accessibility guidelines to be implemented to some degree.

The generally accepted guideline to follow here is the Web Content Accessibility Guidelines (WCAG). The current version of WCAG still is 1.0 (at the time of writing), although v2.0 has been in "W3C Candidate Recommendation" for a few months. WCAG 2.0 is unlikely to change significantly and may be a good basis for developing any applications not due to reach Beta status for a while. Regardless, if a CMS allows sites to meet WCAG 1.0, chances are that with only very minor changes WCAG 2.0 could be reached.

The CMS itself will not "comply with WCAG". But the CMS will offer site developers to meet WCAG guidelines. For example, an image manager should allow the site manager to add an alternate attribute to the image tag. If the site manager opts NOT to use the ALT, it is their responsibility. If the CMS does not allow the addition of the ALT, then it is the CMS’ fault.

Back-end

This is the "admin interface", which most visitors don’t get to see. Only site owners, managers and content developers may have access to this area. Ensuring that the back-end meets accessibility guidelines will allow people with disabilities to manage and maintain the site and the content. Governmental or educational organisations may not currently have disabled employees, but they should not select a CMS that does not allow a potential employee with a disability to do their job – Selecting a non-accessible CMS may lead the employer to discriminatory employment practices! Most CMS do not comply with accessibility guidelines in the back-end.

As well as WCAG, the other set of accessibility guidelines that is of utmost importance to follow is the Authoring Tool Accessibility Guidelines (ATAG). The current version of ATAG is 1.0, and the W3C is currently working on a draft of v2.0.

ATAG addresses both the needs of disabled users wanting to add, maintain and generally manage content or websites, as well as offering the means of content managers to ensure their content is accessible when output to the front-end.

Bells & Whistles

Today’s user expects a CMS to offer bells & whistles. For example, interfaces relying on Asynchronous JavaScript and XML (AJAX) to provide cool effects, or added functionality of controls, etc. However these bells & whistles often come at the detriment of accessibility.

Many developers are aware of, and follow, the concept of "graceful degradation", where a technology such as Javascript may be used to deliver a particular effect, but where the content may still be available if the visitor is unable to use Javascript. In other words, we construct our gizmo and put all the bells and whistles on, and manage to make it work if the bells and whistles are ripped off.

A preferred concept is that of "progressive enhancement", where the system is built with full functionality without requiring often inaccessible scripting. Then the addition of AJAX or other technology improves functionality and usability.

In addition to following progressive enhancement practices, CMS developers have another set of guidelines they may rely on to improve accessibility when using such script. This is the Web Accessibility Initiative (WAI) Accessible Rich Internet Applications Suite (ARIA), or WAI-ARIA. The W3C defines WAI-Aria as:

"the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies."

A Note About Guidelines

It is important to note that while the WCAG, ATAG and WAI-ARIA are important guidelines, they do not represent the be-all and end-all of accessibility. Following the guidelines is a good way to ensure accessible websites and applications, but there can often be room for added accessibility.

For example, WCAG 1.0 suggests the use of "Access Keys" (WCAG 1.0 point 9.5 "provide keyboard shortcuts to important links."). Yet, practicability of this has meant that access keys are often more of a barrier to accessibility than an improvement. This guideline has been removed from the WCAG 2.0 Standard Recommendation.

Another example has to do with styling of links. It is usual practice to style a:hover so when a user passes their mouse over a link, styling changes indicating that they are on a link. What is often forgotten is styling a:focus, which allows users navigating the site with keyboards only to see which link is currently about to be followed. These are what accessibility advocates consider best practices, yet they are not in the current guidelines.

Never forget that the guidelines represent the minimum we should do to implement accessibility.

Guidelines Implementation in CMS

Implementing accessibility guidelines during the development phases of a CMS can be challenging in many respects. There are two positions a CMS may face:

In this paper, we focus primarily on a CMS with existing code, wishing to implement accessibility, as we have done with Mambo.

Implementation Scope

If the CMS hasn’t been developed yet, then the decision is easy: Implement all the guidelines and accessibility features you can.

If, however, the CMS has been around a while, implementation of all the guidelines may not be that simple. With hundreds of thousands of lines of code that are several years old, it may in fact not be logistically possible to implement everything in one go.

This is the situation Mambo faced when we decided to make it "accessible". We analysed where we would get the most "bang for the buck", which would create the greatest positive impact with the least amount of disruption and headache. We originally decided to refactor only front-end output so it would allow site developers to meet WCAG, as well as XHTML 1.1. We also were planning on a few minor improvements to the back-end.

This changed as we considered our long term plans. The codebase was nearly 8 years old at the time. In many ways, it was reaching the end of a useful life. Proper feature and functionality expansion was shackled by reliance on old code that grew in a nearly organic way over the years. We decided to do a complete re-write of the code. A decision was also made to use CakePHP as our framework. While a re-write would implement all accessibility-related guidelines, it would also take a considerable amount of time. Because of that, we decided to expand the work on the last of the 4.x series of Mambo. The dreaded "feature creep" poked its head out, we added features after the deadline! But it has been a conscious decision.

Any CMS facing a similar decision has to carefully analyse and consider their plans and actions.

Concerned Parties Buy-in

In order to successfully implement accessibility, all concerned parties need to buy into this change. It is not always straightforward to get such buy-in from everyone involved. Sometimes an individual doesn’t understand the importance of accessibility. Other times they do understand that accessibility is important, but they believe it is too difficult. The list of reasons is too complex to practicably inventory here. There are three main groups of people that need to buy in to the changes:

Development Team

This is the first and most obvious group. If all the individuals in the development team are not on the same page, friction may develop. It is of the utmost importance that all members of the team have a basic understanding of accessibility requirements, and agree to work together. It may be very tempting for team members to think "yes, ok, accessibility is important, but it’s too hard", and promptly focus on something else. It may not be a bad idea to provide a workshop to all developers on the basics of accessibility. This will help development work and will not put all the responsibility for the integration of accessibility on only one individual.

3rd Party Developers (3PDs)

This group is also important. They need to buy into the changes because often, such changes will impact the interaction of their own extensions with your CMS. This means more work for them. Further than that, if your 3PDs follow you towards accessibility and implement the guidelines in their own application, it means that users of your CMS will have more options for a fully accessible site. You may wish to offer assistance to your 3PDs to help them grow their knowledge of accessibility.

Users

Finally, users – the people for whom, in the end, we are all working. Most of the time selling accessibility to them is relatively easy. Either they don’t really care one way or another, or they are excited at the idea of finally being able to have a site that is accessible and standards compliant. If you have public forum, look at the repeated requests for accessibility. They may not necessarily say "we want an accessible CMS", but they may say "we want tableless output". Listen to them to see how difficult a sell it will be. Chances are, it will be easy.

Technical Know-How

Let’s face it: The W3C Guidelines are clear as mud, on a good day. This may be one of the greatest barriers Mambo encountered in its journey towards accessibility. It is not possible for every member of the team to be specialists in all areas required for development. Without someone with the knowledge or expertise of accessibility issues, it is unlikely that a team would embark on this journey. It would take too much effort to learn the guidelines and keep up-to-date with the changes.

Ideally all developers would have a basic understanding of the concepts of accessibility. This would allow them to identify potential issues and refer to the person who has extended accessibility knowledge. The developers would also know which of the guidelines are mission-critical to provide basic accessibility.

Documenting Changes

Changing towards accessibility may mean making extensive changes in the interface or some of the hooks people can use. It also means changes in the HTML output, meaning that site designs will have to be different (whether you call them templates, skins or themes). Changes should be documented as they happen, rather than wait towards the end of the development cycle. The better and more complete the documentation, the easier it will be for future developers, 3PDs and users to switch to your ‘new & improved’ CMS.

User and 3PD Education

In addition to documenting the changes, Mambo is planning a series of tutorials to assist users and 3PDs in their own transition. This effort requires more time and attention than some teams may think they have. However, it is very important. Planning for tutorials and how-to’s before your CMS release will really help with user uptake.

Trust

Issues of trust (or lack thereof) during accessibility refactoring work can prove to be a serious challenge. If a developer is aware that this may become an issue, half of the problem is already solved. There can be mistrust developing between some of the developers. Those who have expertise in writing PHP (or any other chosen language) may perceive accessibility, or HTML/CSS as "fluff" that just goes over their code, like icing on a cake. As such, they may distrust the ability of the developers who’s expertise lays with HTML, CSS, Accessibility, Usability or Graphical User Interface (GUI). Conversely, it is possible that the people who focus on accessibility dismiss the work of the ‘PHP code jokey’ because they apparently ‘refuse to get it’.

Proper planning and open communication channels are probably the best tools teams have at their disposal to avoid issues of trust.

Conflict Between Technology and Implementation

Difficult decisions sometimes have to be made when a particular technology might improve the user experience, yet cause barriers to other uses. The best implementation is not always using the latest technology. Developers have to be careful not to use a particular technology just because it exists. Yes, AJAX is "cool", but not everything needs to be "AJAXified". Always consider whether a particular technology is required, and if it is, how do you implement it keeping in mind the various guidelines. If you are unable to implement it because your code would require too much re-write, what do you do?

Working With Old Code

Legacy code is in and of itself problematic. Expanding functionality on an old codebase is always difficult. Sometimes, it causes a true barrier to barrier removal. One of the numerous issues Mambo faces with this is the provision of truly human friendly URLs. Because of the database architecture, creating human friendly URLs without server intensive .htaccess rewrites we had to decide to limit the extent of work done in that area before the complete rewrite.

Backward compatibility

Users are asking for backward compatibility. They want to make sure that they can upgrade their site without having to do major work. This is natural. Yet, keeping backward compatibility may shackle a project. How long should a project keep compatible with its older versions? And which parts of the projects need to be kept compatible?

Mambo struggled with this. In the end, we opted to make some changes, aware that some work on templates may be required by our users. But we also ensured that they would have no problem upgrading the database. Depending on the user’s existing template, they may have more, or less, work to upgrade their site. The approach selected was to minimise the negative impact while writing code allowing us to look towards the future rather than behind us.

Conclusion

Amongst all the OS CMS, not many are providing the tools to make accessible websites for visitors that can also be managed by people with disabilities. It is not difficult to understand why: The task of refactoring old code is monumental and requires solid understanding of various accessibility guidelines and of the needs of people with disabilities. Legacy code is often difficult to refactor for accessibility. Writing new software from scratch, starting at > Line 1 is not a prospect many people look upon with joy.

Mambo did decide to do both – refactor the old code to increase accessibility, built-in to the core, rather than tacked on as an after-thought, and undertaking of a complete rewrite. In the process of refactoring, the team expanded knowledge and understanding of developing with accessibility in mind. Various team members added basic (and sometimes advanced) knowledge about accessibility that they have implemented, and will continue to implement, in their coding practice.

For the rewrite, Mambo will use the knowledge acquired during the refactoring. We will be aware of the pitfalls and potential issues, and we have already identified the answers to some tricky issues.

The development of Mambo 4.7 has been long. It has also been delayed a couple times. But we are satisfied that the resulting CMS is as accessible as we could make it with 8 year old code. We are quite proud of both the product, and of the team who completed the work.

Resources & Readings