For CQ5 Users: What You Can Do For Web Accessibility

Recently, and the timing here is purely coincidental, we’ve been ranked “Average” in a Web Accessibility study done by Illinois University.  I know we can do better than Average.  Read more about the study here.

On the development side of the CMS, we take web accessibility very seriously. Because you know, it’s the law and stuff. Also, we certainly strive not to leave anyone behind as far as web content goes. We, at WebComm, have done a lot of customization work on CMS components that automate a lot of the accessible content. However, there are also solutions out there that either we can’t or don’t automate. This post is dedicated to what you can do, that the CMS won’t force you to do for accessibility.

  1. Alt Text on Image Maps.  This is not forced in the CMS, but it SO easy to insert.  Simply provide in the “Text” field of the Image Map menu, a simple description of where the map links to.  That’s it.  Easy as pie.  And really just the decent thing to do.  Screen readers are confusing.Image Map in the CMS
  2. Table Headers. This seems to be a major offense that we got hit on with regard to the CMS.  Guys, PLEASE make sure you have a column header for EACH column.
    Don’t do this:
    bad example of a table in author mode in the CMS
    bad example of a table in publish mode in the CMSDo this instead:
    good example of a table in author mode in the CMS
    Now, there are some things the CMS will not do with the table component, but we’re working with/leaning on the vendor to get these concerns addressed.  Those things being:

    • Table summary, so that a person using a screen reader can have a general idea what kind of data is in the table.
    • Row Headers for Table Rows: Much the same way that we are able to have column headers, row headers are equally useful.
    • Cell IDs and headers to associate the data in each cell with the corresponding column and row.
  3. Alt Text in html Source Images.  If you are inserting an image directly into the source of the text editor or directly into a table.  There is no forced alt text here.  You must provide alt text for each image, even in the source, if you want to be compliant.
  4. A Single h1 Tag.  Please use only one h1 tag per page.  This h1 tag should be the title of your page or a general summation of the data on your page.   To those using a screenreader, it’s helpful to know generally what is the general idea of a page.  If it isn’t applicable to what information s/he is after, s/he can look elsewhere for that information instead of having to sit and listen to everything on the page.   You can be technically compliant with two h1 tags for pages with very little content that maybe you’d like to consolidate, but as a general rule, please stick with one.It is not meant to emphasize urgency to a particular piece of text. To CMS users, it means use only ONE title component. If you aren’t using a title component, use only one H1 on a text or text image component. But don’t use them together.  This can become confusing using a screen reader when you can’t tell what is a title and what is just meant to be emphasized.  Example of what NOT to do:
    Bad example of H1 Usage
  5. Use tables for tabular data only, not for layout.  Screen readers can’t tell the difference between tables that you use to hold a page structure and tables used to present data to the user.  Unless you just arrived here in a time machine from the late 90s, this should be standard practice as a web content author.  And hey, for redundancy’s sake, make sure those tables have headers on each column.  The above table (step 2) is an example of acceptable table data.

If you aren’t compliant, you open us all up for a lawsuit.  This really isn’t a choice.  Here is what the CMS will do automatically.

  1. Provide a skip nav link.  Currently, this is not visible to users, and all CMS pages are technically compliant, but there is development in the queue to make this link “visible” in that it will be navigable by keyboard, so that even without a screen reader, users with assistive technologies are also able to skip repetitive lists of links.
  2. Force alt text on images within OU Image Component and OU Text Image component.  If you are using these components traditionally (not altering source HTML), alt text is forced upon every image.  Please make sure it is descriptive, and not just garbage typed in to avoid the big, ugly, red error message
  3. Alt text on the random image component, if not provided within the component, is fetched from the Digital Asset Manager.  So unless you want specialized alt text on those images, you don’t have to do double duty (once on the component, once in the dig asset mgr) to enter alt text.  Because it’s really fun doing things twice.

Again, this is really the responsibility of everyone at the university to make sure that we either are compliant with 508 standards, or are on our way to becoming complaint.  No, using the CMS doesn’t automatically make you complaint, but we are working hard to make it easier to be.  Please pay attention to what you are putting out there.

Here are some links to some lawsuits to Universities like ours, who got hit with lawsuits for not being accessible!  Let’s make sure we are never one of them.  But more importantly, let’s become a leader in this kind of initiative for Web Accessibility.  There can never be too many advocates for this kind of thing.

University of Arizona Kindle lawsuit

Penn State lawsuit

One thought on “For CQ5 Users: What You Can Do For Web Accessibility

Leave a Reply

Your email address will not be published. Required fields are marked *