Over the years Blue Fish has been asked to build Web Content Management solutions for a wide range of clients. With any WCM solution, our goal is to enable non-technical users to create and maintain a highly usable website. Section 508 of the Rehabilitation Act of 1973 specifically mandates that government and government funded websites be accessible for handicapped individuals, but many of our clients are simply interested making their site usable by peoples with vision disabilities.
Many of the good design decisions and development habits that we follow can help make your website accessible to the visually impaired – even if the law does not mandate your website to be Section 508 compliant. In general, these practices result in solutions that are more useable for persons with and without disabilities. So even though your website might not be required by federal law to meet the standards laid out in Section 508, you might just find that implementing some of the ideas that follow will result in a better website.
To be clear, I’m not describing a definitive “How To” with this article. Nor are we trying to explain a solution for every single facet of Section 508 of the Rehabilitation Act of 1973. There are plenty of resources available on the web that details the minutiae of Section 508. By leveraging some of these tips on your Web Publisher based WCM solution, I hope you’ll enhance the accessibility and usability of your website for all users regardless of health and disabilities.
Most companies and organizations that wish to make their website accessible for the visually impaired or disabled follow the technical standards defined by Section 508 of the Rehabilitation Act of 1973. Section 508 codifies those technical requirements and all Federal agencies (as well as private institutions that receive funding from or under contract with a government agency) must meet during the development, procurement, use and maintenance of information technology solutions. The standards defined in Section 508 are intended to give disabled users – whether they are government employees or the public – comparable access to the information available to all other users which is why so many websites are designed to meet the standards regardless of legal obligation.
With regards to websites and other web based solutions, Section 508 provides sixteen provisions that must be met for a solution to be accessible to disabled peoples. These sixteen provisions are laid out in Sub-part B, 1194.22 of Section 508 and are widely detailed on various web resources, so listing them in this article would be redundant at best. The ultimate goal of the sixteen provisions – and the following best practices – is to ensure accessibility for visually impaired persons using assistive technologies such as screen readers by providing contextual text labels and descriptions for graphics, navigation, and other web page elements.
Although originally added in 1986 as an amendment to the Rehabilitation Act of 1973, it was not until 1998 that the current implementation and enforcement of Section 508 came to fruition. It is a common misunderstanding to think Section 508 is part of the Americans with Disabilities Act of 1990; Section 504 of the Rehabilitation Act of 1973 was the basis for the ADA, but that is the only connection. Similarly, the World Wide Web Consortium’s Web Content Accessibility Guidelines (WCAG) are related to – but not part of – Section 508 compliance. The WCAG are voluntary and unenforceable whereas Section 508 provides a course of action against violators of the law. In the case of the WCAG, there is indeed significant overlap between the guidelines and the sixteen provisions outlined by Section 508. In some instances, adhering to just one set of rules could quite possibly result in complete compliance with the other set, but the only way to ensure 100% compliance with Section 508 of the Rehabilitation Act of 1973 is to explicitly check against all sixteen points.
Section 508 of the Rehabilitation Act of 1973 is in place to guarantee that disabled users of a given website can access the same information as all other users. There’s no guarantee that disabled users (or anyone else, for that matter) will be able to actually use the website efficiently and effectively.
When I first started designing and building WCM solutions, I used to spend a lot of time at the end of projects checking that the resulting website was accessible. Over time, I realized that if the website was designed for usability, the accessibility often came for free. A few simple tips to remember when designing for usability will also help accessibility include:
At this point, many of us are familiar with color coded alerts and stoplights. It’s intuitive to many that red means “danger” or “stop” and green means “safe” or “go”. Unfortunately, for a disabled user of your website – for example, someone with color blindness – differentiating red, yellow, and green icons might not be possible.
For example, in Figure 1, the availability of Apple’s iPhone is indicated on a per store basis solely by the color of the stop light.
Using Color As The Sole Indicator
While the availability indicated in this image may have been intuitive to you and me, it’s not even necessarily readable to an individual with color blindness. Rather than just relying on green vs. red, Figure 2 shows a more accessible and useable representation of the same information from another website.
Using Color and Other Indicators
Figure 2 is a much better usability and accessibility decision; There is no mistaking that there are two states – in stock vs. out of stock – because the icons are not only two different colors, they are two different shapes.
How many times have you read through a long block of text on a website and, at the bottom, been presented with a link that merely says “Read More”? If you’ve been reading a lot about ACME corporation, the real question is “Read More What.” By changing that link text to say “Read More About ACME’s Solution”, you’ve already made the page significantly more user friendly.
By using descriptive text for links and buttons, as described in the simple example above, your website moves closer to being Section 508 compliant. A disabled user who is visiting the website with a text reader isn’t going to have the visual clue that the “Read More” link is directly below a huge block of text about ACME’s Solution. What happens if there are multiple “Read More” links on the same page? Changing the links to say “Read More About ACME’s Solution” and “Read More About Working For ACME Corporation” is inherently more usable and accessible for all users.
Not only does using contextual and descriptive text for links and buttons make your site more usable, it will likely help with your search engine ranking.
Text Based Page Elements
Instead of using images for these page elements, simply rendering text over backgrounds looks just as great as using images and makes updates relatively painless for content authors. In this example, the business user is able to perform changes without having to call up the resident Photoshop expert to get a new image ready to go.
When you use a content management system with templated authoring – such as EMC Documentum’s Web Publisher – to administer your WCM solution, you inherently gain the power to change one template and apply those changes to all the relevant instances of content. While designing our clients’ Web Publisher based solutions, a few common patterns repeatedly appear in the website markup that can be easily applied to all pages thanks to templated authoring. These little tweaks to your markup will not only result in a more usable site for all visitors, but will help your solution achieve Section 508 compliance.
Imagine your favorite e-commerce site with 10 tabs across the top of the website and an additional 5 or more submenu options that appear every time you mouse over one of those tabs. Each one of those 10 tabs and 5 dropdown options is HTML that will be read by the text reader on every single page load; If you’re not visually impaired, it’s hard to fathom listening to a site reader read back 50 or more navigational elements before you even find out that the product page you’re viewing isn’t the right product.
While it’s easy enough for most sighted users to focus immediately on the body of the page and skip the global navigation, the same is not true of disabled persons using a site reader. By including a link to the meat of the page at the very top of every page, a visually impaired user can quickly jump over the navigation.
It’s just common courtesy and good practice to give every visitor to your website a quick path to the heart of every page.
One of the most important provisions of Section 508 of the Rehabilitation Act of 1973 is that all images must have alternate text descriptions. While it may be obvious that regular content images need these descriptions, it’s easy to overlook all those site assets – like spacer images and logos – but they too must have descriptions. During construction of your presentation files, set the
alt attribute for the
img tag appropriately. For blank images used as spacers, an
alt="" is perfectly acceptable for Section 508 compliance.
It’s easy to forget that not every user is visiting your website with a mouse. Quickly check all your markup files for device specific references (such as
onMouseOver) and change them to device independent instances (such as
In addition to the aforementioned design decisions than can be easily incorporated into your XSL presentation files, there are a few tips and tricks that can help ensure your Web Publisher based WCM solution is Section 508 compliant.
As mentioned earlier, a prime directive of Section 508 is to ensure all images include descriptive alternative text for the visually impaired. While it’s straight forward enough to hard code
alt attributes in the XSL presentation files for site assets, what about images added or selected by content authors via the Web Publisher content editor?
There are two ways that content authors can add images to an instance of content in Web Publisher:
When a content author selects an image using the Graphic Widget (Figure 4), Web Publisher does not allow the author to enter any descriptive text to be use as the
alt attribute for the published rendition.
Image selection widget
A simple straight forward solution is to include another field in your template that allows a content author to enter a description (Figure 5).
Alternate text description entry
Now your XSL presentation file can render the
img tag with both the
src attribute from the graphic widget and an
alt attribute using the descriptive text. If this description field is optional, Section 508 compliance can still be ensured by generating an
alt attribute text from the image name in the XSL processing, but this will only ensure compliance with the letter of the law, not the spirit. To make your site truly accessible, every image should have a descriptive
If a content author adds an image via the Rich Content Area widget, the author can add the
alt text description by either right clicking on the image and selecting “Image Properties” or double-clicking on the image. At that point, the content author can enter the descriptive text in the “Alternative Text” field of the “Image Properties” window shown in Figure 6.
Image Properties for a Rich Content Area image
Another major provision of Section 508 is to ensure accessibility of data contained in tables. Similar to images, tables are required to have descriptive identifiers to be Section 508 compliant.
Section 508 has two requirements related to tables:
Since visually impaired visitors are unable to ascertain the contextual clues (such as color highlighting) that might indicate a table has a header row, these two requirements ensure accessibility. In general, tables should be properly formatted and used for data representation, not for general page layout.
Like images added via the Rich Content Area widget, Web Publisher enables content authors to easily identify and mark tables as necessary to be Section 508 compliant. By highlighting the table cells, right clicking, and selecting “Cell Properties”, a content author can quickly add the appropriate tags to make a table Section 508 compliant. The “Cell Properties” window (Figure 7) allows an author to mark rows and/or columns as header cells (important for requirement #1) as well as set the Header ID and the Headers attribute (both important for requirement #2).
Cell Properties for a Rich Content Area table
By checking the “Header cell” box, the previously selected cells are changed from td elements to th elements. Assistive devices will read this markup and inform a user that these cells are header cells and not data cells.
To link a data cell with a header cell, as required by #2, a content author can set the “Header ID” on the header cell(s) and then set the “headers” on the data cell.
As with rich content area images, there is no way to be certain content authors have properly entered these descriptors for a table. Blue Fish uses processing in the XSL presentation file as well as best practice education during training to help our clients ensure compliance.
Beginning with D6, Documentum has included a new option – the Accessibility Report — for the Rich Content Area widget in Web Publisher. This option, when enabled, allows content authors to generate a variety of simple reports for a rich content area that highlight potential compliance issues.
To run the Accessibility Report, a content author clicks on the accessibility report icon in the rich content area toolbar (Figure 8 ) and is presented with the report window (Figure 9).
Rich Content Area toolbar
D6 Accessibility Report
The accessibility report window allows content authors to check against both Section 508 as well as the WCAG standards. Additionally, by checking the “Errors”, “Warning”, and “Manual Checks” boxes, the content author is given different information to consider for the content’s compliance. This new tool combined with the best practices already outlined can help ensure Section 508 compliance for Web Publisher based WCM solutions.
While documented as an option for the Rich Content Area widget in D6 and D6 SP1, how to enable the Accessibility Report toolbar option was not documented at the time of publication. To enable this option, the following steps must be taken.
In the /wp/wp/editors/contenteditor/resources/editliveConfig.xml file located on the Application Server:
Accessibility="Y"to the appropriate
Compliance with Section 508 of the Rehabilitation Act of 1973 is required for all government affiliated or funded websites to ensure accessibility for all visitors. With a little bit of foresight, adoption of some best practices, and good overall usability, compliance for your website will come almost naturally. Regardless of whether or not your website is required by law to be Section 508 compliant, enacting many of these recommendations will help create a solution that is more useable for persons with or without a disability.