Tuesday, September 23, 2008

Accessibility In Suit And Tie

The life of the corporate web worker who cares about standards and accessibility can be a frustrating one; hampered by office politics and archaic content management systems. In this article, Bruce looks at what you can do to make sure your projects are as accessible for your users as possible.

The gap between the high-end standards-aware freelance developer with the freedom to choose and the corporate web worker is a wide one, and it doesn’t look as if it’s likely to narrow any time soon. But, just as not every start-up employee skateboards from meeting to meeting coding Django on her iPhone, not every business suit uses FrontPage to juggle his marquee tags. There are many corporate developers who do care about cross-browser compatibility, semantic code and accessibility.

So this article is for the suits who care: if you can’t use cutting-edge tools, technologies or techniques, what can you do to ensure that you’re doing all you can for all of your users? My tried-and-tested method is:

  1. Get buy-in from the top
  2. Some accessibility is better than none
  3. Educate your content providers

Get Buy-In From the Top

The last major redesign project I was involved with was successful from an accessibility point-of-view because we had buy-in from the board. Having convinced the top brass of the need for accessibility we wrote a “constitution” for the new site that says all content must be accessible to people with disabilities, and where this clashes with aesthetics or organizational convenience, it trumps them. If you read it, you’ll see that I’ve sneaked in some accessibility-related rules under a different guise.

The CEO then sent this to all the directors. The advantage of this is clear: when a content owner is exasperated at the time you spend marking up a long important document rather than simply linking to a PDF of the Word document they gave you, you can just point out that you’re just doing what you’re told and invite them to complain to the CEO.

Achieving Buy-In

One problem with corporate accessibility is that while corporations generally care about accessibility in the abstract (because they don’t want to get sued, and they don’t want negative publicity), they don’t actually understand how to show that they care. In my own experience, working for a UK legal regulator, accessibility is seen as a legal compliance issue (”does this comply with the DDA?”) which can lead to a grudging attempt to be accessible, because a corporate lawyer will naturally try to do the minimum required to stay in compliance; minimizing risk while minimizing costs.

The way to overcome this is to focus on the customer. I find the following arguments successful in getting accessibility discussed in a positive, “good-to-have” way rather than in a legal compliance “oh-well-if-we-must” way:

Some Accessibility is Better Than None

I often see standardistas boast "I don’t care about accessibility" because it’s assumed to be inherent in standards-based development. (I doubt that’s true if you’re making Ajax pages, as you’ll need WAI-ARIA attributes to be added to HTML elements in order to ensure accessibility).

But that is based upon the premise that your web infrastructure and office politics mean that you’re able to do standards-based development. Assuming you have a website that deals with the storing, manipulation and display of company data, you’ll need a CMS of some kind. The best code is produced by the best CMSes, and many of those are unavailable to corporate developers because:

  • they’re open source and most corporate IT departments don’t like open source, due to perceived "risk" and lack of someone else to shout at if there’s a problem
  • they are free or very cheap (this is why start-ups often have better tools than big corporates with deep pockets: they use the free ones like WordPress, PHP, Rails, Drupal, etc. because they have to)
  • they are very new and don’t have a pedigree that reassures those whose job depends upon procuring the right CMS
  • there’s a feeling that they can’t possibly compete with costly behemoths like Sharepoint, Teamsite, Vignette (AKA "no-one ever got sacked for buying Microsoft")

We could talk all day about why terrible tools are so prevalent. (In my experience, the reason why a terrible tool isn’t replaced is because someone senior paid $500,000 for it and sure as hell isn’t going to admit a mistake and scrap it.)

Working Around Bad Tools

The terrible tools can hamper your efforts to be accessible in several ways. One of the worst ways it can do this is by having some archaic WYSIWYG editor that allows authors to cheat and make “headings” by choosing size and colors which are translated into font tags on the front end, and therefore there is no structure for an assistive technology user to navigate by.

You can cure this by with a CSS rule that naughtily over-writes the tag: font {color:red; font-size:xx-large; text-decoration:blink; background-color:yellow;} which means content authors see hideous flashing text. It will, I guarantee, encourage them to write proper headings.

Sometimes, terrible tools have to be worked round. You might never be able to get 100% valid code, or remove all the nested tables that you’ve added into pages just to stop them looking atrocious.

But that doesn’t mean that you won’t make a difference if you do what you can. While I was working on The Law Society website we had thousands of pages in the CMS that were full of tags, double-
s to separate paragraphs and some table layout. Even if we could have run a script over the proprietary database to change those, it wouldn’t have been good use of our time, as every page would still need to be manually verified.

However, the site-wide header and navigation was controlled by a single include file, so we amended that to change the navigation from elaborate tables with bullet to be a CSS-styled unordered list. It would be easy, with such an architecture, to add some WAI-ARIA document landmark roles to help screenreader users. These changes were comparatively simple and made screenreader users’ lives much easier. The site will never validate, or win a clean code award, but it’s more accessible than it was.

Incrementally Improve the Code

So you know you have loads of bad markup and “imitation” headings lurking around, but fixing them all will take too much time and effort. Sort out the biggie pages, such as the home page, “contact us” page, “about us” page and the other top 10 high-traffic pages (check your server logs) straight away.

Whenever any other page needs any kind of editorial amend, take a few minutes when the page is open for the editorial change to correct the markup, too. You’ll find that the most commonly updated pages will be corrected first, and they’re very likely to be most-important or most-visited so a sort of "accessibility through natural selection" process takes over.

Educate Your Content Providers

Most big corporates have multiple people throughout the business submitting content for publication. Generally, they aren’t web specialists and submit their content in Microsoft Word format. It’s vital to give them a Word template that defines the styles they can use for bullets and numbering, etc., so they don’t get a nasty surprise when they see that their lovingly-created purple lightning-strike bullets haven’t made it onto the website.

Consider organizing half-day training sessions on how to use Word styles so that headings are methodically created rather than imitated with font size and bold. This pays off as there is no ambiguity if you’re having to mark up their content by hand. (I would have killed for a Word macro that converted documents into HTML with no style information, only the structural information. If you know of one, please tell the world!)

If you have to publish in PDF format, it will be more accessible if it’s made with a proper Word structure. (Adobe has published a useful cheat sheet on how to author Word files for conversion to more accessible PDF.)

Get Your Content Providers Writing HTML

Go mad! Dream big! Turn off the WYSIWYG, throw away Word and train your content providers to deliver you HTML. Most web content (as opposed to headers, navigation, forms, etc.) consists of a few conceptually simple elements:

  • headings
  • paragraphs (including abbreviations)
  • links
  • bulleted/ numbered lists

So train people to send you the content ready-marked up. It won’t be perfect, but it’s simple to run it through HTML Tidy to make it validate. It will be shorter and better-structured if they have to consider the heading hierarchy. Of course, you will still need to add the more complex elements like images and data tables yourself, but they are rarer, so your workload will diminish, their control over the content will increase and your users will get a more accessible website.

Accept the Compromises

It’s hard, when you’re a professional, to accept that something you produce is less than perfect. But all web design is a compromise: liquid layouts versus line length, design versus page weight, and so on. Complete accessibility is never completely achievable as there is such a vast range of needs. So, be a zen master and accept the compromises: simply by caring and trying to do what you can, you’ll make your company’s website more accessible and lives of your disabled visitors easier.

via :thinkvitamin

Labels:

posted by Subodh Kumar @ 10:38 AM   0 Comments


0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home