Web Accessibility
Content Management Systems Can Improve Accessibility
by Jim Howard
02-Apr-2004
Creating web sites accessible to those with disabilities can prove challenging for a variety of reasons, not the least of which is the diversity of potential disabilities among your visitorship, as well as the spectrum of issues within any single impairment category. For the purposes of this article, I'll focus on publishing for the sight impaired, merely as an example of the greater challenge as a whole.
In my opinion, the best way to achieve accessibility-compliant websites is to generate multiple sites. For starters, a publisher can create two sites -- one for use by those who navigate via a standard browser, and the other for those who rely on sound to navigate with a "screen reader" for the blind and visually impaired. (While other special web browsers exist for users with disabilities, for simplicity's sake we'll call them all "readers" from here on.) Trying to have a single website that works for multiple navigational approaches results in a site that is difficult to use for all kinds of site visitors.
The good news is that any organization with a web content management system in place should be able to publish multiple sites fairly easily, thereby meeting accessibility requirements in a much more successful way. For example, with two sites it becomes possible to deliver a far superior product to the blind and visually impaired, while also delivering on the letter and spirit of accessibility laws.
Designed to be Seen or Heard?
Is your site accessible? Well, the marketplace is full of products that can tell organizations when a site is out of compliance, according to that product's particular interpretation of a certain accessibility standard. That's good, but not good enough, since a list of the non-compliant code is much easier to generate than replacement code that complies with accessibility standards yet still delivers a usable site for the visual browser.
These error-detection products often pitch follow-on consulting services to help you rewrite your site into something that complies with accessibility standard while still operating for visual browsers. Some argue, however, that delivering a site that is visually attractive and navigates well for visual browsers as well as hearing-based visitors -- let alone people with other disabilities -- is simply impossible. I find that argument a bit strident, but believe nonetheless that pursuing the single site approach for audiences with multiple accessibility profiles means facing inevitable trade-offs in both usability and visual style.
This is not just an issue for websites. Consider a house designed to be livable, comfortable, and attractive for a sighted person. Architects concentrate to a great extent on the use of light and space, and count on the house's occupants using visual cues for how to interact and function. Now imagine designing a house for a visually impaired resident, who might require touch and sound as the cues for how to get around. The entire way of thinking about design changes.
Similarly, good web designs use visual cues to tell visitors how to navigate, show inter-relationships between content elements, weigh the importance of content, indicate content categories and hierarchies, and convey the type of content. All of these things tend to break down quickly for hearing-based navigators -- even when accessibility guidelines are followed. Delivering a quality site for hearing-based visitors requires totally different thinking about navigation and information presentation.
This may well represent the best part about a multisite approach: you can do more than achieve compliance -- you can optimize the online experience for disabled visitors. For example, the best hearing navigator-focused sites take a very different approach to linking, titling, and content organization. They also incorporate some simple tricks to greatly speed navigation. A special link to "jump directly to content" and skip that page's navigation is very helpful, for example. Providing titles to the list of links, or even spelling out what the list of links is about can let a hearing-based navigator share the same visual clues that show a sighted navigator which links are major or minor, higher or lower in hierarchy, etc.
Addressing the range of disabilities for the vision impaired, from "low vision" to completely blind, is absolutely critical to consider as well. Remember that low vision visitors are likely to require large fonts and still desire images, and that text-only sites can be a poor substitute for them.
The clear upshot here is that different web sites are the way to go. Then organizations that care about accessibility can have visually attractive, highly functional web sites for browsers and easily navigable sites for readers. Let's put an end to accessibility being the excuse for ugly, clunky design, especially in government sites.
Accessibility Compliance & Web Content Management
Without a content management system, owning and managing multiple web sites -- one for use by browsers, one for use by readers -- means twice the work. With a good content management system in place, however, new content can be added once and published to two or more sites effortlessly. When a visitor comes to the web site, the web server can detect whether a web browser or a reader is requesting the page, and deliver up the correct site. In this way, everyone receives a site optimized to the way in which they access the web.
Working with multiple sites isn't all peaches and cream, of course. Templates for two or more sites still need to be proactively designed, especially if you give careful attention to navigability for the impaired. Nevertheless, for experienced web design firms, converting a site from browser-exclusive to reader-focused is a straightforward project because the content is already categorized and organized. A good design firm should be able to create a new navigation scheme and new standard presentation templates, which can then be built into the web content management system and presto -- your content becomes more accessible.
Even better, CMS templates can be easily modified to make changes or improvements site-wide. This is important, because Web accessibility remains a young discipline:
- standards sometimes change,
- implementation practices and standards interpretations are evolving,
- new reader technologies are emerging,
- webmasters continue to report good suggestions arriving from disabled site visitors.
With a CMS, you can publish completely new sites to accommodate specific new readers, or to meet conflicting requirements. And as an added bonus, your CMS can generate other types of content as well -- perhaps a wireless version, an XML version for an RSS feed, or a headlines-only version for use by a ticker display. That's just good business.
When it comes time to redesign the browser-focused site, though, it will also require some adjustment of other renditions in the CMS system. Even if layout templates don't need adjustment, a new site organization and categorization scheme may require some template tweaks.
All Compliant Now
In an interesting development, a few CMS vendors have made claims that their product is able to ensure compliance with accessibility standards. Well, of course they can. So can any decent CMS package with a reasonably robust templating engine. If HTML or XML code can be written to meet a standard, then templates can be built to output content within that framework. A vendor may offer pre-fab web templates they deem compliant with a particular standard, but it is unlikely that those templates are perfect for any given site. Take the necessary time and effort to design properly for your audiences. [Ed.'s note: CMSWatch is convinced and will incorporate many of these suggestions into a forthcoming site redesign.]
What About Content Contributors?
Another noteworthy dimension to accessibility compliance is the interface to CMS products themselves. I believe that the software products themselves will almost always suffer accessibility problems, especially for the blind and visually impaired. Much of what a CMS product addresses is visual in nature. Selecting images, managing layout, and working with visual cues to show site visitors where to go, are core elements of a system's usefulness.
However, the most important part of the CMS, content authoring, can easily be accessibility compliant -- through email. Email is one of the best -- albeit infrequently supported -- methods of content contribution. Those CMS products that support content import via email can accept content from any web form or email engine, and thus become compliant in a meaningful way.
Which Standard?
Unfortunately, accessibility standards have problems. There are so many "standards" that even the most motivated organization may well find themselves out of compliance somewhere. Many of the standards do not reflect the way screen readers work today. In an informal test using the newest version of the IBM ScreenReader 4 product, my QA staff was able to navigate many of the sites they visited -- even some that seemingly made little effort toward accessibility compliance. In fact, some of the sites that offered an accessibility-compliant alternative became downright painful to navigate, with dozens of repetitive links and text at the top of every page before getting into the content.
One mandate that gets a great deal of notice is Section 508 in the USA, which describes fairly complex (or at least less than straightforward) requirements for making web sites accessible by screen readers for the blind and visually impaired, and includes some elements for people with epilepsy. Most US federal agencies work hard to fulfill the spirit of the legislation, but actual implementations vary substantially, and diverse interpretations continue to proliferate as new screen readers come on the market.
The European Union, Canada, Australia, Japan, and many other national governments as well as most US state governments have also proposed or established accessibility standards for the web. Perhaps most meaningful of all standards may be the W3C Web Accessibility Initiative, which has published its own Web Content Accessibility Guidelines. The W3C guidelines aren't just for Web Content, though. They have also published guidelines for Authoring Tool Accessibility, User Agent Accessibility, and XML Application Accessibility, as well as detailed content on techniques and other resources. Their work likely inspired and informed much of the world's government activity to date.
In summary, one needs to consider the goals of an accessibility program based on standards and guidelines, but also the higher-level objective of achieving accessibility. And the good news is that a CMS package can help you adapt as guidelines and technologies evolve.
Why Not Be Accessible?
A quick message for organizations considering accessibility compliance: Think again about content management software. With some additional design and template work, your (potentially expensive) accessibility compliance problem might just go away. And that could pay for the CMS project in one motion.
A quick message for organizations considering a web content management project: Why not add accessibility into the mix? It probably won't cost much, it will provide a great benefit to a small but important segment of your site visitors, and it could bring you into compliance right away.
A quick message to organizations trying to build one site for both visual and hearing-based navigators: Try using a few screen readers on your web site and ask yourself if you have really helped the blind and visually impaired, or if you are just building a lesser site for both audiences.
A Few More Resources
A list of Worldwide Government Policies, Standards and Regulations
The NY Institute for Special Education Blindness Resource Center