Content management systems (CMS) have evolved from the basic templating systems of the mid-90's to enterprise-wide knowledge management tools and integrated collaboration applications. They have even taken on a personal touch through the introduction of mature weblogging systems.
Content management will continue to be relevant because it represents a reasonable approach to the development and archiving of Web content in diverse organizations. It is important, then, that these systems take into account the needs of users with disabilities, not only in using CMS products, but in guaranteeing that they can use all of the content that is stored within. Since changing a few templates can on some CMS-client sites cause millions of documents to be altered, the accessibility of content management systems in aggregate impacts the overall accessibility of the Web immensely.
According to a 1998 report by the U.S. Office of Disability Employment Policy, people with disabilities in the United States alone control $175 billion in discretionary income. People with disabilities represent a growing market, as users discover the resources available to them on the Web, and represents a large and vocal audience. While early in the development of the Web authors may have designed a text-only site to mollify that audience while they created inaccessible core sites, this tactic is now viewed negatively, and many Web site developers are now reacting to the needs of users with disabilities by designing flexible, standards-based sites. These authors are now in need of a generation of CMS that will assist them in maintaining these sites.
Human authors tend to write inferior markup. The errors and inconsistencies resulting from many hand-coded sites, ranging from invalid content to atrophied coding practices, add up to a fragile and complex framework for future development. The long-term value of a CMS in the enterprise relies on its ability to streamline the processes currently associated with Web development, including validation, accessibility, internationalization, design and refactoring exercises.
Statutory requirements may direct the creation of accessible content management tools. Legal mandates in many countries and municipalities figure into purchasing decisions. The U.S. federal government's adoption of Section 508 means that CMS vendors must ensure compliance with a set of accessibility requirements in order to sell their products to government agencies or their contractors. Australia and Canada have more specific sets of requirements, based in part on W3C/WAI's Web Content Accessibility Guidelines (WCAG) 1.0. Additionally, the European Union Member States, individually and as a whole, have adopted or are considering requirements based on WCAG 1.0, and in some cases, the W3C/WAI Authoring Tool Accessibility Guidelines (ATAG) 1.0.
The market for standards-conformant and accessible CMS is not limited to what is required by law. The private sector is in increasing numbers seeing the benefit of increasing their potential audience and reducing development costs using standards-based, accessible design. For example, IBM, Hewlett-Packard, Wells Fargo and Fleet have adopted company-wide policies specifying accessible Web content. Vendors who produce a CMS that satisfies the requirements of these customers stand to benefit greatly.
ATAG 1.0, a W3C Recommendation issued in December 2000, was written to assist developers in authoring tools that produce accessible Web content, along with accessible authoring interfaces. ATAG 1.0 covers Content Management Tools, defined as "tools that assist authors to create and organize specific types of Web content without the author having control over the markup or programming implementation." This definition includes the current set of CMS products, as well as knowledge management systems, learning management systems, and weblogging tools.
The ATAG Recommendation contains in-depth information on the requirements of tool accessibility, along with sets of techniques providing objective testing criteria. Conformance of a tool to ATAG indicates that its output is readily able to produce Web content that conforms to the requirements of WCAG.
The task of designing accessible practices into a CMS workflow may seem daunting. It's important to note that ATAG doesn't aim to automate all accessibility repair into each tool: some of the requirements for accessibility rest squarely with the content provider. The goal of ATAG is to automate what can be done by machine, seek input where assistance can aid the designer in creating content, and otherwise allow the author to do anything else that's necessary to increase accessibility. Put another way, if the tool knows how to do it, it should do it; if it doesn't, it should get out of the way.
The key elements of any CMS product with respect to accessibility evaluation and remediation are: accessible content creation and editing; accessible collateral; accessible templates and documentation; and accessible interface.
For systems that accept plain-text input for distillation into HTML or other formats, or those that transform content from other systems such as Microsoft Office, those distillers should be designed to create valid, semantic HTML. Avoid presentational elements such as the <font> element and spacer GIFs; instead, use CSS to preserve presentation.
For WYSIWYG-style tools, or tools that accept content marked up in HTML or XML, the input markup should be tested for validity, as well as the presence of metadata and alternate content. At a minimum, tools should not strip elements and attributes that are not understood by the tool. These techniques prevent the "garbage in, garbage out" cycle of inaccessible content, and aids future accessibility remediation, as well as future migration projects.
Maintaining a database of stored collateral is generally helpful on a large site, and many CMS products allow non-text content to be managed, indexed, etc. Adding the ability to associate alternate content can aid accessibility and archival aims.
Images should have alt text attached and stored in the repository. This will have the side effect of aiding searchability of collateral. At the same time, images should not be bound exclusively to one block of alt text, because alternative content is often based on its surrounding context. Authors should be able to attach relevant alt text to content in the repository, even when other alt text already exists. There should be an additional space for storing long descriptions (the "longdesc" attribute on images and image form elements in HTML) for cases where detail needs to be described to blind or low-vision users.
Similar functionality is necessary for multimedia. Presentations such as Flash- or SVG-based movies may have textual alternatives, or they may have other non-text content designed as a replacement. Audio content should have a linked transcript. Video has more intensive requirements: namely, accessible forms of video require both captions for deaf and hard of hearing users, and audio descriptions for blind or low-vision users. Describing the requirements of captioning and audio description are generally out of scope both for this paper and for most content management systems; still, it is important to ensure that alternate content can be bound to video and audio, and exposed as necessary at rendering time.
Templates are commonly bundled with CMS tools across the board. In many cases, such as weblogs, the basic template provided with a tool may be used with no or only minor changes. It makes sense, then, that vendors should make that bundled content as accessible as possible.
Whether or not they are used verbatim in many sites, they are still cannibalized or used as models for the creation of customized document templates. The bundled content, including samples and documentation describing how to create sites, should implement accessibility features by default.
Accessibility on the front end of a CMS has two elements: exercising quality control on incoming content, and offering an accessible interface to CMS content providers with disabilities.
All systems should validate HTML- or XML-based input before storing that content in the repository. The principle of "garbage in, garbage out" applies here, and the effect of invalid stored content is a cascade which is very similar to the dreaded intermittent bug in software development. Most content may turn up in testing to be valid, but invalid when applied to content. When content owners attempt to test their sites with accessibility evaluation tools, many of which check validity, they may not be able to determine or resolve issues with content chunks or templates effectively. It is important to adequately encapsulate content chunks to ensure that, when juxtaposed with templates, the combination validates to published grammars.
CMS tools can integrate accessibility tools themselves to increase the quality of input. For example, tools to check and repair table markup to include summary, caption, headers, etc., would make the production of accessible content simpler. Likewise, finding and marking up abbreviations and acronyms using the <abbr> and <acronym> elements would give important context that could be used by people with disabilities such as dyslexia or semantic-pragmatic disorder, as well as subject-matter novices and search mechanisms.
Systems that use a non-Web application interface (e.g., a Windows-, Mac- or Unix-based application for data entry) need to be designed to conform to their host operating system's accessibility guidelines.
Web-based CMS front ends should ensure that their forms, scripts, and interaction implement accessibility features. Forms can have their labels attached in HTML using the <label> element. (An added usability bonus of this approach is that, as in many familiar operating systems, clicking on the label draws focus to its attached element.)
According to the Web Content Accessibility Guidelines and the U.S. Section 508 standard, Web content must be functional without script. This seems to preclude such things as form validation via JavaScript, but this content can likewise be validated on the server. The key to implementing script accessibly is to apply server-side solutions for problems presently being solved on the client, and ensuring that buttons and other interactive elements are attached to HTTP URIs, instead of using the javascript: URN, which causes deadlocks.
ATAG 1.0 has seven guidelines for creating accessible tools:
Any tool that confuses or is unfriendly toward accessible design is going to hinder it. Unfortunately, this is the case with most products for creating Web content. Quite often, tools manipulate markup for their own convenience in processing, discarding accessibility-related content, or failing to allow such content to be added. The first guideline in the Authoring Tool Accessibility Guidelines 1.0 indicates that authors should be able to utilize the accessibility features of the languages supported by the tool.
Content management systems should not hide or strip content not understood by the tool. Erasing existing content for the convenience of the tool often results in the loss of most accessibility-related markup, including alt text, descriptions, abbreviations, and table markup. This most often occurs during data capture, or in transformations or conversions. A rule of thumb for this is: handle what you know, preserve what you don't.
Guideline 1 sets requirements for the provision of templates that conform to WCAG. Given the sheer number of documents that can be served from single templates, it is only logical that bundled templates should be accessible themselves.
Valid, standardized markup is crucial to accessibility. Given that a wide range of assistive technologies use Web content, from screen readers and magnifiers to Braille displays to customized browsers for users with learning disabilities, all users benefit from an understanding of the semantics provided by languages like HTML. Valid content additionally facilitates cross-platform and cross-browser compatibility, since most modern browsers agree on how to render valid content.
Authoring tools must by default create content that validates to published grammars. If the final output turns out to be invalid, for example if the author's portion of the template is invalid, tools are encouraged to evaluate and inform the author of the problem.
Tools can play a major role not only in staying out of the way of authors creating accessible content, but in simplifying the process for creating or adding such content.
When dealing with collateral such as images and video, CMS products should prompt authors for alternative content, such as alt text on images, or audio descriptions and text transcripts for video. This content should be bound together with the collateral in the repository, and authors should be able to edit and manipulate the collateral and its alternative content.
However, at no time should a tool fabricate alternate content if this material does not exist and is not known: for example, if an image has no alt text in the repository, but is known by the CMS to be a link to the home page, the tool may use "Home" as the alt text; however, if it is an image with otherwise arbitrary meaning, the CMS should not try to fabricate an alternative.
CMS vendors should ensure that any templates bundled with the system have accessibility features integrated by default. The principle is familiar: first, do no harm. Tool vendors should be testing their templates against the Web Content Accessibility Guidelines as they are created.
Likewise, all authoring tools should work to keep the structure of a document separate from its presentation. This means that content in repositories should not retain presentational data such as <font> elements or spacer images in HTML; instead, this information should be implemented in CSS.
Even if the CMS provides flawlessly accessible content by default, accessibility can be compromised by poor quality of authored content. To solve this, authoring tools can implement accessibility evaluation and repair functionality. For many customers, this is a convenient means of preserving their content. But in situations where accessibility is required by law, such as U.S. and Australian federal agencies, the ability to set policy based on the provision of adequate accessibility features may be a central purchasing factor.
A CMS could design an accessibility check at publishing time, or after data entry, and guide users to repair content to a more accessible state. Overall accessibility checks of the system, producing a status report for review, is also helpful.
As important as it is to have this functionality in authoring tools, it is not going to assist accessibility if it is not discoverable or familiar to the user. Guideline 5 of ATAG states that functionality that is related to accessibility should be a natural part of the authoring process, and those features should be "among the most obvious and easily initiated by the author." This is easier for many CMS products to satisfy than for shrinkwrap tools, since publishing rules are centralized, and content can be controlled more easily.
Accessible help, documentation and training is hugely beneficial to creating usable sites. A fairly small minority of Web developers understand the principles of accessibility, while others, particularly the market catered to by CMS products, may not know anything about the problems, or even that a problem exists in reaching people with disabilities online.
It is important, then, that the issue of accessibility, and the proper uses of the tool to solve them, is detailed in product documentation and online help. CMS tools that test for accessibility should provide explanations for any error messages. Accessibility-related features can be integrated in example code throughout the documentation, as well.
People with disabilities are not just consumers of content, they are also producers. With that in mind, ATAG specifies requirements for applications that generate content. In addition to conforming to operating system accessibility standards and conventions, tool developers should ensure that users with disabilities are able to navigate, edit, search and manage content within the interface.