MySource Matrix Section Name

Content Tools

Main Content

An Accessible Business Case for Web Site Accessibility

A Wider Audience, More Traffic, Happy Users, and More Cash

Executive Summary

Having an accessible web site will, without question, improve your commercial performance.But sadly web accessibility is also a boring, technocratic subject that's usually championed by non-commercial people who speak in alien tongues.

As a result, when it comes to building or running web sites, accessibility rarely features on the development agenda (or when it does, it comes after some lengthy, impenetrable techno-speak on wiki's or widgets).It's perceived as a luxury item for all but the most cash-rich (or highly regulated) web organisations.After all, people with disabilities are such a small minority, so how could you possibly justify the extra expense?

Well, if you take this view then you're missing the point and you could be making a very expensive mistake.For whilst it's true that people with disabilities represent only a small fraction of your total audience, building an accessible web site is not just about catering for their needs and being legally compliant.Nor is it just a task for the techies, and it’s certainly not expensive.Its benefits are far more fundamental and it needs to be a top commercial concern for your business.

In simple terms, being accessible will help you attract more traffic, generate more leads, make more money, and drive more awareness of your products and services.Got your attention? Great.Then let's take a look why an accessible web site makes such good commercial sense and how you can start designing for Accessibility today.

Accessibility Payoffs - What it's Worth to Your Business

Accessible web sites enjoy many of the following benefits:more site visitors, better user experiences, a wider range of users, lower maintenance costs, faster development times, increased reach, lower development costs and less legal exposure.

Let's take a quick look at each of them...

More site visitors

Good accessibility practice is almost identical to good search engine optimisation (SEO) practice.This should come as no surprise to you if you know your SEO:Google’s search ‘spiders’ tend to read web pages in much the same way as humans, and so making your pages more ‘accessible ’ does a lot of good for both types of reader.We’ll cover the technical aspects of this later, but for now you should know that if you make your pages more accessible then a primary payoff is better Google performance on search terms that are related to you.Which in turn means more site visitors, and ultimately more sales / sign-ups / awareness / education / conversions (delete as necessary - whatever your ultimate aim, these objectives must be the core of your web strategy).

More usable

This is the end game of accessibility - to make your site usable for people with disabilities.How it’s done properly is the stuff of debate amongst web developers, but from a commercial perspective all we need to understand is a simple distinction in web terminology:namely, that the practice of ‘usability’ will help everyone without disabilities to use your site, and that ‘accessibility’ efforts will help everyone (period!) to use your site more effectively.

Stop and think about that for a minute.Who would you rather have using your web site? I thought so. We all want everyone, all of the time. And, as we’ll see, since the cost of developing for basic accessibility has no discernible extra cost or time penalty, it ought to be very attainable.

Good Accessibility practices will therefore help all of your users to use your web site more effectively, all of the time.In practice this means placing human concerns ahead of technology or design concerns - ie, assuring that folks can navigate your page, fill out your form or complete their payment transaction rather than implementing that really cool widget or rendering the page with a purple and black ripple effect.This in itself is common sense as it helps you to realise your most important commercial goals.

More users (able and disable)

This is the net effect of building an accessible web site.   Because it’s more usable, more people can and will use it.  Now, the key point to establish here is what ‘more users’ means.  Ideally ‘more’ means everyone, including those with disabilities, but I realise that you may not care for disabled people if they don’t need your products, services, or information.  So why care?  Well, building for ‘more users’ really means building for those people who are ‘less able’ than you are, and these folks may be simply:

  • Short sighted (but not short of cash)
  • Older than you (but more interested in you than the ‘average’ web Joe)
  • Less familiar with the web (less comfortable with a mouse, but very much so with budgets)
  • Temporarily less able than you (they broke an arm playing polo at the weekend)
  • Linguistically challenged (but experts in their fields)
  • Technically challenged (accessing your site via a hotel’s 56k connection)
  • ...or plain old disabled (over 500 million people!)

Now, which of these people do you care for? I’m sure you get the point.Designing for Accessibility will challenge your assumptions in a profitable way.

Lower maintenance costs

Without diving into the technicalities (we’ll look at these later), we can say that building accessible sites requires a specific approach to planning and implementation that’s desirable in all cases because it will reduce your ongoing running costs.

In basic terms this approach necessitates the use of a good Content Management System (CMS) - a web-based software application that makes it easier and more cost-effective to publish your web site, and whose genius lies in its ability to separate the presentation (design) of a site from its content (the words and pictures) such that it allows non-technical users to focus on writing content (in a ‘Word’-like fashion) whilst the techies and designers can concentrate on presentation (ie, creating the code that dictates look and feel).

As such, a CMS-based site will allow you take simple publishing and editorial work away from technical specialists (people who are not known for their appreciation of copywriting or  corporate policy) and give them to the right people for the task.  For example, in a magazine, a CMS will enable editorial staff to publish to the web without calling in the tech support team; and in a software company, it’ll allow marketing staff to publish press releases themselves.

Faster development times, lower development costs and broader reach Aside from helping non-technical people to publish web pages and reducing your maintenance costs, a CMS which manages your content as a separate entity will also help you to be more nimble when it comes to developing new web site channels or services.

Let’s say you decide to create a new site for mobile users.It needs to be optimised for a micro browser and it needs to be leaner, with fewer images to ensure speedy access times.  Now, if your content isn’t tied to the presentation of your original site (by virtue of being hardwired into the page code), then you’ll be able to develop the new service in half the time.

In effect, all you’ll need to do is to keep the content separate and run it through a new design template (one that prescribes a different set of layout rules - such as the use of your low bandwidth image library rather than its high resolution counterpart) and serve it to users via a different domain.  In turn, you can use this principle to create a whole stable of sites that are optimised for different audiences and different access devices - for example, a text-only version for users that are visually impaired.

In technical terms, I’ve just described how Cascading Style Sheets (CSS) work.A style sheet sits between your content assets and a user’s browser and dictates how the content is to be presented.  If you use them, then it’s a lot easier to build for the future because a new site or service will mean changes to your presentation ‘layer’ only, rather than forcing you to rip everything up and start again.  And so the use of style sheets will allow you to cost-effectively develop a separate, accessible version of your site, or at the very least enable you to make it more accessible by letting you tweak it more easily.

Less legal exposure

The benefits listed above ought to provide you with the motivation to build for Accessibility, but if they don’t then the final reason is to avoid getting sued.

Your web site is your door onto the world, and it needs to be hinged properly so that you can get out and your audience can get in.  At the same time, you must realise that you can’t restrict your audience - the web is extremely open by nature - so you have to build and design broadly.  This means ensuring that your content can be accessed by absolutely everyone, otherwise you run the risk of being sued on a discriminatory basis.

To Be or Not to Be:The Accessibility Question

OK, so we care about Accessibility because it’s good for business, but what does it mean to ‘be accessible’?

This needn’t be a subject for navel gazing.  In practice, being accessible means sitting on the right side of the law.  If your organisation is designed to serve everybody then your web site needs to do so as well.  It’s simply a question of equal opportunities, backed up by statutes from the United Nations (General Assembly resolution 48/96 of December 1993, to be precise, which states that all business and public service organisations need to provide equal access to all of their information and communication as well as their physical environments).

From a legal perspective, this means we’re heading towards a new era of law suits.  Simple surveys show that around 50% of web sites fail basic Accessibility tests, and there are a number of complaints currently in session around the globe.The gist is broadly the same - people with disabilities are suing companies and organisations for locking them out of their content.

Now this shouldn’t come as a surprise as web development technology moves far, far too quickly for site users to keep up.  When you consider that most major software companies also consistently fail in this regard - for example, their browsers are often incompatible with new variants of Javascript - it seems that everyone is doomed to remain inaccessible forever.

But the reality is not that grim, because as luck would have it someone is thinking about these issues for us.  And, if we follow their advice everything should be fine - users will have access and companies will stay out of court.

The World Wide Web Consortium (W3C, see: http://www.w3.org/Consortium/)was formed in 1994 to tackle a variety of important issues including Accessibility.  It exists as an international advisory panel and think tank, creating a bunch of technical guidelines to stop the world wide web from becoming the wild, wild west.  One of its missions is to advise us on how to design for Accessibility, and its guidelines are published under the acronym WAI (the Web Accessibility Initiative), which can be found at http://www.w3.org/WAI/.

The guideline has three best practice checkpoints (called ‘Priorities’) which act as a ‘how to’ style checklist for web developers.  They’re based upon a measurement of impact on Accessibility, and they are:

  • Priory 1:  A web site MUST pass this level, otherwise one or more groups will find it IMPOSSIBLE to access information on the web site.
  • Priory 2:  A web site SHOULD pass this level, otherwise one or more groups will find it DIFFICULT to access information on the web site.
  • Priory 3:  A web site MAY pass this level, otherwise one or more groups will find it SOMEWHAT DIFFICULT to access information on the web site.

To keep things simple, if you can pass Priority 1, then you’ll be servicing a wider audience and enjoying all of the commercial benefits previously mentioned.  And the good news is that this isn’t difficult or expensive.  WCAG v1.0 basically requires that you make your content “understandable and navigable”.

Here’s what it means to satisfy ‘Priority 1’ requirements (you can read this guideline in full at http://www.w3.org/TR/WCAG10/):

“Content developers should make content understandable and navigable. This includes not only making the language clear and simple, but also providing understandable mechanisms for navigating within and between pages. Providing navigation tools and orientation information in pages will maximize accessibility and usability. Not all users can make use of visual clues such as image maps, proportional scroll bars, side-by-side frames, or graphics that guide sighted users of graphical desktop browsers. Users also lose contextual information when they can only view a portion of a page, either because they are accessing the page one word at a time (speech synthesis or braille display), or one section at a time (small display, or a magnified display). Without orientation information, users may not be able to understand very large tables, lists, menus, etc.”

A Word About Your Audience

At this point it’s worth painting a picture of who you’re designing for.As already mentioned, you need to be thinking of older, less technically equipped, less experienced, and/or disabled people (or a combination of these things).  Your audience in many cases will be using a variety of ‘Assistive Technologies’ - or gadgets to help them access your content.  These can be described as follows:

Screen Readers:software applications that ‘read’ web pages and files to their users

Screen readers do what they say on the tin - they ‘read’ whatever’s on the user’s display back to them.  They do this in two ways:firstly through audio (and speech synthesis) and secondly via Braille outputs.  Users with disabilities may use a combination of both.All screen reading technology has a method - a way of translating web page and application code into speech or Braille - and this tends to be via a process known as ‘linearization’.  Linearization basically means taking the screen content and reading it in a linear fashion, from left to right and top to bottom.  Different screen reading technologies may have different capabilities on this score, but by and large this rule holds.  This is important to understand, because a linear ‘reading’ of a web page is very different from a standard interaction.  When we view a page we never read in a linear way.  Instead we zip around the page, scanning madly until our eyes rest on whatever it is that holds our attention.  Therefore, a ‘screen read’ experience of a web page is fundamentally different to a normal visual experience.

Talking and Text-Only Browsers: web browsers that either ‘read’ pages or render them in plain text format

A good example of a talking browser is IBM’s Homepage Reader - an extremely functional and cost-effective solution for many with disabilities.  Like a screen reader, it also ‘linearizes’ the page experience. Text-only browsers, as you might expect, render web pages as text and strip out any images or stylistic formatting.  This is the web at it most rudimentary, but using one to view your own site can be extremely informative: it’ll tell you at a glance how well you cater for many Accessibility requirements (all of which we’ll look at later).A good example is the Lynx browser.  Talking- and text-only browsers are readily available and cheap.They should be a standard implementation and testing tool for web developers that are designing for Accessibility.

Screen Magnifiers:software applications that increase the size of whatever is displayed on screen

Screen magnifying applications enable users with standard monitors to ‘zoom in’ and magnify to different proportions.  It’s a simple concept, much like using the spyglass feature in an image processing application.  Windows XP and Vista bundle a Magnifier application  within the standard operating system package.

In addition, a variety of specialist input devices will be used, and it should be assumed that a mouse will not be a standard tool for navigating around the screen (keyboard strokes may be the dominant method).

Web Accessibility Guidelines at a Glance

With this in mind, here’s a quick run through of the WAI guidelines for ‘Priority 1’:

  1. Provide equivalent alternatives to auditory and visual content
  2. Don't rely on colour alone
  3. Use markup and style sheets and do so properly
  4. Clarify natural language usage
  5. Create tables that transform gracefully
  6. Ensure that pages featuring new technologies transform gracefully
  7. Ensure user control of time-sensitive content changes
  8. Ensure direct accessibility of embedded user interfaces
  9. Design for device-independence
  10. Use interim solutions
  11. Use W3C technologies and guidelines
  12. Provide context and orientation information
  13. Provide clear navigation mechanisms
  14. Ensure that documents are clear and simple

Web Accessibility Guidelines Explained

Now let’s look at each of them in more detail... In this section we’ll describe the guidelines in basic terms, and in the following section we’ll look at the various technical approaches you can use to address them.

  1. Provide equivalent alternatives to auditory and visual content

    This guideline asks you to ensure that when visual and auditory content is used to convey information and/or meaning, then alternative text-based content is also provided.A good example of this is providing alternative text descriptions for photo images or graphs.  In the case of animations or video, a transcript should be provided.   These text descriptions can be easily parsed by screen readers and Braille displays, and can be presented visually (in a variety of sizes) on displays and paper.

  2. Don't rely on colour alone

    Or, to be more exact, don’t rely on colour alone to convey information.... because this may render it inaccessible.For example, some web sites use a coloured ‘tabbing’ design convention to denote sections within a site in the same way that tabs are used for separating hard copy filing systems.  Now, this is fine if the tabs are accompanied by words (For example, Amazon, who uses tabs to denote different product categories) because screen readers and other assistive technologies can process the information, but if the colour alone is used to convey the tab’s meaning then users of all stripes will have trouble figuring out what they’re for.  In addition, attention should be paid to ensuring that foreground and background colours are clearly defined as they may not provide sufficient contrast for some users.

  3. Use markup and style sheets and do so properly

    This requires developers to abide by a set of best practices when coding a web site.  The guideline asks for cascading style sheets (we’ll look at these in detail later) to be used at all times, which makes for better, cleaner code (by separating content from presentation), and for coding conventions to be followed precisely so that content can be read more easily by assistive technologies such as screen readers.

  4. Clarify natural language usage

    This point simply asks developers to make it clear, within their code, which language the content is to be presented in – English, French, etc - so that assistive technologies can make the distinction and render the content accordingly.

  5. Create tables that transform gracefully

    In basic terms, this rule asks that tables be used for sensible things (such as displaying rows and columns of data) as opposed to being misappropriated for other uses.  For example, tables are often used as a quick (and lazy) method of controlling page design layout.  This requirement is necessary because assistive technologies make assumptions about how to interpret data within tables, and if they’re used for things like page layout then this will confuse them and their outputs.

  6. Ensure that pages featuring new technologies transform gracefully

    This guidance is necessary to ensure that when a new piece of technology is applied to a page (for example, a whizzy new Ajax interface) then it will still remain accessible to users whose tools (browsers, screen readers, etc) are not yet able to use it.

  7. Ensure user control of time-sensitive content changes

    In some cases, moving content can be a barrier to Accessibility - it can have a detrimental effects such as obscuring the rest of the page for people with cognitive or visual disabilities.  This includes presentation styles such as moving, blinking or scrolling text (eg, a ticker tape).  As such, it’s recommended that you provide users with tools to turn off this type of content easily.

  8. Ensure direct accessibility of embedded user interfaces

    If a function of the page has its own interface (for example an interactive game that sits within an entertainment site) then it’s important that it is device-independent in terms of functionality and control.  For example, an interface should not be built solely for use with the mouse, because people with physical disabilities may not be able to use it.  And, if the interface can’t be made accessible, then an alternative accessible solution must be provided.

  9. Design for device-independence

    Like the point above, you should ensure that the user can interact with your web pages with their preferred input (or output) device - mouse, keyboard, voice, etc.

  10. Use interim solutions

    Of all the guidelines, this point is probably the most open ended and demanding.  In short, it requests that developers build sites with the limitations of assistive technologies in mind, such that if a piece of new and unsupported content is used then an alternative means of Accessing the content is also provided.  Fortunately, the scope of this can be limited:  rather than requiring an in-depth knowledge of every possible assistive solution, you can keep on the straight and narrow by conforming to current browser capabilities because assistive technologies tend to stay in sync with them.  In other words, if you know the limitations of past and present versions of Internet Explorer and design your functionality accordingly then your site ought to work fine.  And, frankly, every web developer should have this knowledge.

  11. Use W3C technologies and guidelines

    This point is self-explanatory.We’ll discuss accessible implementation technologies and how to use them in the next section.

  12. Provide context and orientation information

    13. Treat your web site as you would if you were designing a traffic flow system - signpost it clearly and wisely.  This guideline simply asks you to provide context and orientation information to help users get around your site (and not to assume too much on their behalf!).  You can do this by grouping certain page elements together and providing contextual information about the relationships between them.  For example navigation schemes should be designed as whole pieces of content so that they’re obvious to access, and they should be clearly supported by signposts such as ALT text descriptions.

  13. Provide clear navigation mechanisms

    Navigation is such a key part of your site that it’s worth a whole focus of its own.  The WCAG guideline states that you should “provide clear and consistent navigation mechanisms - orientation information, navigation bars, a site map, etc - to increase the likelihood that a person will find what they are looking for at a site.”

  14. Ensure that documents are clear and simple

    This recommendation should be standard practice for every web site.It asks that every page should be made “clear and simple so they may be more easily understood.”  This adds up to a tick list of effective web design:  ensure that page layouts are consistent, render graphics is an easily accessible format (and with alternative text-based descriptions), and deliver your content in language that’s easy to understand.

A Kitbag:Things You Need, Your Foundations

An Overview of What You’ll Need

Back to basics.Content is only accessible if it can be ‘viewed’ by everybody.  Here’s what we’ll need to build accessible web pages:

  • HTML and XHTML
  • Cascading Style Sheets
  • Some Javascript and Java
  • Flash
  • PDF’s
  • Video (Quicktime, Windows Media, etc)

And that’s it.In fact this stuff is the bricks and mortar of every web site, accessible or not.  Contrary to conventional wisdom, building and designing for Accessibility is NOT restrictive.You can use Javascript and you can use Flash.  The difference is that all of these things need to be implemented with care and attention to detail - something that the web design community is not necessarily noted for.

Your Foundations...Cascading Style Sheets (CSS)

As the W3C suggests, the right way to build a web site is to use cascading style sheets (CSS) to define how a page is presented to the user (in terms of look and feel), whilst your HTML will describe the page content and structure (in terms of words and images and where they’re placed on the page).  As a foundation for sites, this approach has evolved over time to counteract the problems associated with hardwiring content and presentation together (some of which are outlined above).  The latest versions of XHTML (v2.0) has removed all styling attributes such that in order to present a page, a developer has to use CSS.

The reason this is so important to Accessibility is that assistive technologies such as screen readers are programmed to focus on page content rather than page styles so that users can use their assistive tools to tweak the content to their own needs.For example, some browsers will allow you to view sites through your own style sheets - say with all text in a large Ariel font to enhance readability.And so the technical discipline of well structured style sheets forces developers to create clean HTML (and good styling) so that a page will make sense even if the style sheet is taken away.  (Again, it’s worth remembering that the web is an extremely open place where you can’t even control your content, let alone your users..... so you’d better build using good, clean code that doesn’t prevent this sort of thing.Besides, clean code and smart use of style sheets - particularly when used in tandem with a good CMS - should always be desirable.)

To recap, the wider benefits of CSS and content separation are faster development time and lower ongoing maintenance costs.  In addition, you should pay attention to the longevity of your site - it’s far more likely to be around in two years time than the guy who built it, so it’s worth ensuring it gets built in a way that others will understand.  Again, clean code, good annotation and above all the use of style sheets is essential.

OK, you have the foundation, now how do you build your site?

The Accessibility Commandments:How to Build for Accessibility (and Therefore Enjoy Other Good Things)

In this section we’ll take a quick look at how to best use each of the ‘kitbag’ technologies mentioned above as well as the Accessibility business benefits for each style of implementation.  But first a disclaimer:  this paper is designed to take the Accessibility debate into the boardroom.  It’s not a technical ‘how to’ guide.  So for all you technical readers I’ve annotated the following sections with links to related W3C pages where you’ll find all the coding resources you’ll need.

  1. Accessible Images, Audio and Video

    The Issue

    The question of non-textual content is the mother of Accessibility issues.  It covers:  images, image maps, buttons, video, audio, and various other multimedia (such as Flash).  In simple terms these are all things that use visual or audio information to convey meaning, and so they can cause problems for people with hearing or sight difficulties.  The problems are, however, compounded when you begin to look at the way most assistive technologies work - such as screen readers - as these tools are smart but not smart enough to interpret a Flash demo or an image button that says ‘sign up here!’.  The way they tend to work is to ‘read’ the text that’s provided in the page content and relay that back to their users.  And there’s the crux.  Good accessibility requires developers to supplement non-textual stuff with good, clear textual content that can make assistive technologies behave smarter.

    The Solution

    In short, the solution is to provide text equivalents for all non-textual content.

    For example:

    • All images that perform functions (such as ‘sign up’ or ‘go’ buttons) must use ALT text to describe what they do.Further, these descriptions should be as specific as possible (think of describing the action performed by the image, not just what it looks like!)
    • All images that don’t carry information (such as styling elements) should NOT carry ALT descriptions (because that’d just confuse things!)
    • Charts and graphs should provide some level of description - as detailed as possible when dealing with complex representations
    • Images that are used for linking (for example navigation ‘tabs’) should provide ALT text descriptions
    • For more complex files and images, such as video or Flash presentations, it’s best to provide a transcript or summary of the content, so that users can at least get a grasp of what’s going on within the page.

    In addition, all of the aforementioned ALT descriptions ought to be well written with one eye on how they’re to be used.For example, screen readers will read back all accessible text on a page, so you can afford to be concise where things are obvious to avoid repetition and boredom for users.  Not everything will need to carry a brand name within it and phrases should be trimmed to convey meaning only - it’s all about functionality as opposed to copywriting creativity.

    The use of ALT text and descriptive elements around content ought to be standard practice for every web developer.  But when it comes to Accessibility, the difference lies in thinking harder about the meaning that’s conveyed by each description and how one may interact with it using a variety of assistive technologies.For this reason, it’s good to do some testing along the way, by running pages through screen readers, text-only browsers and the like.It’s also a good idea to have someone with disabilities use your test pages to give you more immediate feedback.

    Business Benefits

    If you follow the advice above then Google will simply love you.Why? Well, in a nutshell, good SEO works in the following way:Google (and other search engines) get to know you via the ‘bots’ or ‘spiders’ that they send out to review your site.  So the end game in SEO is to help them to understand who you are and what you do by providing as much practical information as possible within your code - preferably in the shape of the keywords (or search terms) that you’d like to be associated with.  In practice this means ‘marking up’ your links, headers, tags and such with extra descriptive information. Google’s spiders will then ‘read’ this information and categorise you accordingly.

    In short, SEO best practice asks you to provide descriptions of your content for the benefit of a bunch of software agents.  Accessibility best practice involves providing descriptions of all your non-text content for a bunch of assistive technologies.  It’s the same process..... only if you’re doing it with Accessibility in mind you can guarantee that the quality of this extra layer of descriptive content will be of better quality - after all, your writing for humans not software.  So, in short, good Accessibility ‘marking up’ of content is manna for search engines.

    Further Resources

    The Issue

  2. Accessible Colour

    One in twenty of your site visitors will have problems defining colour perfectly.  So you need to pay attention to things like contrast and colour combinations.

    The Solution

    Basically it’s fine to use colour to convey information, but it’s not OK to use colour alone.  I hinted at this earlier on using the example of tabbed navigation.  Tabbed navigation that uses different colours to convey different product categories along with the labels ‘Books’, ‘DVD’s’, etc is fine, so long as the information on the labels is rendered as text or ALT text is used to describe them.  But problems would be caused if colour alone were used for this kind of label, because it provides us with no meaning other than a visual distinction.

    Business Benefits

    This ought to be obvious.Our tabs example is one of extremely poor design execution.  Who wouldn’t want labels that help users navigate around a page? The benefit of designing with accessible colours in mind is that you’ll end up with infinitely more usable web pages - pages that will be understood at a glance and fit for use by the widest possible range of people - young, old, new to the web and experienced.

    Further Resources

    3. Accessible Tables

    The Issue

  3. ..is twofold.  Firstly tables are often used (wrongly today) for controlling the layout of a page.Secondly, they’re (rightly) used for displaying data.

    In the first instance, the use of cascading style sheets (CSS) to control the look and feel of web pages should be mandatory - we’ve discussed the benefits in detail.  This in itself will negate the use of tables, but if table use is persistent, here’s the problem:  most assistive technologies read tables in a linear fashion, and this may bear no relation whatsoever to the way in which the content is rendered visually on the page.I won’t dwell on this point - the resources section here will point you to more examples and a deeper explanation of the problem.  For now though, you should understand that when tables are used to help alignment of navigation schemes, main page banners and content cells, technologies such as screen readers and text only browsers will chew them up and rearrange their contents in an undesirable way!

    In terms of using tables for the presentation of data, the crucial thing to care about is the way rows and columns are labelled.  After all, financial results, software features and sports stats only make sense if you know what they’re referring to, because the meaning of a number in a row will depend on the label applied to it in its corresponding column header.  As such, the aim is again to ensure that assistive technologies can ‘read’ your data table headings in a linearized fashion.

    Now, when reading data tables we tend to skim them and pick out the information we care for. For example, we may be interested only in who Liverpool FC are playing in March, and not the rest of the year.  Screen readers on the other hand can’t get inside their user’s minds in this way to make selective choices, so they read out data in sequence.  For example:  ‘Liverpool, January 5th, vs Arsenal, January 12th vs Aston Villa’ and so forth.   As such, we need to ensure that our tables are rendered cleanly, with no confusion in sub headers that may throw assistive technologies off course.

    The Solution

    The way to design accessible tables, even when they’re multi-layered and complex, is to ensure that they are marked up and styled thoroughly (using CSS).  By this, I mean to say that different headers within a table (the rows, sub-rows and columns) should carry appropriate header tags and not be rendered at the same level (ie, the same style).  It gets more complex than this in terms of generating neat code, but I’ll leave that for your further reading.  For now you should appreciate that accessible tables are all about using good, well marked up style sheets.

    Business Benefits

    Once again, the over-riding business benefit is the use of style sheets.By forcing developers to use them, designing for Accessibility ensures that future development costs, maintenance costs, and training costs (of new developers) can be limited by ensuring that page code is as clean as can be and that presentation is always separated from content.  Again, a CMS will help here, which will bring the added benefit of enabling non-technical people to author your site.

    Further Resources

    The Issue

  4. Accessible Navigation and Linking

    Aside from the images issue, this is the other Accessibility classic.  Think about this for a second - how often have you arrived in the guts of a web site after a Google search and felt dizzy and disoriented?  I’m sure it’s happened at least once today.  Now, imagine that you were either partially sighted, unfamiliar with the web, or unable to use a mouse fluently.  Where to begin!?

    The question of accessible navigation is therefore all about the ease in which users can get around your individual web pages.  Sure, there will be persistent navigation aids throughout the site - such as your primary scheme (About Us, Products, Services, etc), but there will also be a multitude of unique elements on specific pages:  for example, “Download Now!”, “Sign Up Here!”, “Add to Basket!”.In this sense, many of the elements already discussed will come into play. We need to ensure image buttons are rendered with alternative descriptions and that blocks of similar content are laid out in obvious chunks to help users around the page.  Also, where image maps are used for blocks of navigation (ie, when large images are preferred to web text layouts), then they should also be marked up clearly with alternative descriptions.

    In addition, you must consider how your text is rendered on the page.   If you’re a magazine and each of your article pages has a headline and a sub head, how much text (navigation or otherwise) appears above them on the page?  This is important, as assistive technologies will play back (or lay out) all of the page content, in sequence, from start to finish as it appears in the page source code.  Now, imagine this in a text-only browser:  your headline may be buried, in a single font size, underneath eight lines of extraneous text.  We need to understand that many of the visual cues that are designed to help standard users become irrelevant, and hence inaccessible.

    The Solution

    As mentioned before, where images are used to convey information instead of text, then explicit alternative descriptions should be used.  Where navigation is concerned, these descriptions should hint at the actions they perform - eg, “Skip to Main Page Content” (which is a very important piece of navigation for those with disabilities).  Assistive technologies are trained to describe links in distinctive ways to help users, so in this example, the user may hear:  “LINK - Skip to....” or it may be read out in a different voice style to normal text.

    Think also about how your content is rendered in the source code.  If you’re using style sheets then there’s no reason that all of that other text bumph needs to feature above the page name or headline – the important stuff can feature right up at the top, so that assistive technologies ‘read’ it first.

    Also, it’s possible to leave various navigational ‘markers’ within the page that are invisible to users who are NOT using assistive technologies - like the “Skip to...” link mentioned above, which is often hidden behind some white space in a page header.  Take a look at the source code of any major news web site and you’ll probably see this in use.  Why?  Well, imagine you’re using a screen reader and navigating from home page to section page to news article within a magazine.  Without these kinds of shortcuts you’d have the dubious pleasure of listening to the site’s ad banners, navigation schemes and various other content elements read out to you time after time before you reach the content you’re after.  As such, “Skip to Maim Page Content” is an invaluable aid.

    Business Benefits

    Firstly, good accessible navigation requires the use of style sheets, whose benefits ought now to be very clear.  Secondly, designing for accessible navigation forces designers to think through wider issues of usability.  And, if your site becomes more usable for everyone then it’s likely to be more profitable.  If creative types are asked to think deeply about how and where an “Add to Basket” image button is rendered on the page, then the result is likely to benefit everyone.

    Further Resources

    The Issue

  5. Accessible Forms

    6. “Web Forms” may sound like a dull subject, but think about how dependent we are on them.  A form is used on most web sites for a number of purposes:

    • Buying stuff - filling out credit card information
    • Signing up for stuff - providing your name and email address
    • Creating user accounts - registering your address
    • ...etc

    In other words, web forms underpin all forms of web commerce.

    Now, think about how you last used a web form.  Did you use your mouse for the task, to click between form fields (to get from “first name” to “surname”)?  Probably.  Now what if you couldn’t use a mouse efficiently?

    The Solution

    The good news is that there’s more than one way to control your movement around a web page.  Try using your tab key - it’ll shift your control point between links on the page.  When it comes to forms, this is also the case, you can skip from one cell to another with just a keystroke.  In addition, forms will require an action button (“Go”, “Buy”, “Sign Up”, etc), and so can be made accessible by providing alternative text-based descriptions as already discussed.

    The key to accessible web forms is, however, the text descriptions that are used to facilitate your data input and how they’re coded within the form’s containing table.  As mentioned before, assistive technologies tend to ‘read’ source code data in a linear fashion, and each will have its own quirks when it comes to playing back that information to users.   So, when it comes to forms, they had better be rendered in an accessible way, or chaos will follow!

    How do you do this properly?  Well, the easiest thing to do is to render prompting information amongst the code to help users understand that this is a form and not just a standard piece of content.  This prompting info can also give guidance as to what is requested of the user for each form cell (eg “First Name”, “Surname”, etc).  Often, you will want some form elements to be mandatory (eg, email address), and so this should be clearly labelled if forms are to be completed (and validated) successfully).  Further, you need to ensure that tables are rendered cleanly and styled well - again using good CSS - so that they can be read in a linearized fashion.

    Finally, forms need to report validation errors clearly, so that when errors occur, users know how to correct them.  Just highlighting a phone number field in red isn’t going to help all your users.  Instead, there are ways in which this error information can be returned with descriptions and links that take users back to the form field in question with a simple click or keystroke.  (Check out the resources below for further information on how this can be done.)

    Business Benefits

    In short, accessible forms require smart use of style sheets because they’re usually rendered using tables.  In addition, just like the points raised in accessible navigation and linking, designing for accessibility forces creative and technical staff to think through bigger picture usability issues that will help to make your forms more effective - such as, “What’s the best way to describe what we need in this form field?”  Good answers to these questions will help all of your users and result in more successfully completed forms and a higher satisfaction level amongst customers.  (How often have you wanted to throw your keyboard at your monitor when a credit card transaction form fails at the last minute for no discernable reason!?)

    Further Resources

    The Issue

  6. Accessible Javascript

    7. ...is a thorny one.  Ask one developer what she thinks of the accessibility merits of Ajax (a new Javascript method that enables page content to change without refreshing the entire page) and her head will spin.  Ask your lead developer what your web site would be without Ajax and they’ll probably quit immediately.  The truth is that Javascript in itself is not bad for anyone’s health - it’s only harmful when the wrong kind of human is applied to it.

    The benefits of Javascript are large.  Faster page interaction (no waiting for reloads) and the creation of slicker, more application-like interfaces mean that the user experience is vastly improved.  The downside of Javascript is also large.  Here’s a few:  pop ups, banner ads that float like annoying ghosts across your screen (seemingly always on car sites!), scripts that turn off some of your basic controls (like the ability to do things with a right click), browser-sniffing scripts that tell you things you don’t want to know (“You’re browser isn’t compatible, you must upgrade now!”).  Overuse and/or misuse of Javascript is therefore an irritant for everyone.  So let’s see how it should be done...

    The Solution

    Bad Javascript is bad Javascript implementation.  Using dodgy, reusable code from bad libraries.  Smearing irritating stuff across the page.  You get the idea.Good Javascript assumes the following: 

    • ...that Javascript might be turned off at the browser end of things
    • ...the user owns their browser and so is always in the driving seat
    • ...page use and, meaning and content are not relayed exclusively through Javascript
    • ...you follow strict coding standards

    Implementation of good Javascript requires a certain level of expertise and technical know how, plus an appetite for staying up to date (approaches such as Ajax never stand still!).  However, for the purposes of this document, and much like the best practices discussed before, the key lies in separating out your code into constituent parts - in this case structure (HTML), presentation (CSS), and behaviour (Javascript).  If you mix these up, you’re going to create problems for assistive technologies that need to parse the information.  Further, you need to provide alternatives to your Javascript elements, in much the same way as you’d provide alternatives for image based navigation.  The most responsible way of implementing it is, therefore, to assume that nobody can use it, and to give them signposts and other tools for getting things done.  For further technical and real implementation advice, see the further resources section below.

    Business Benefits

    By separating out the various elements of code you’re again insuring yourself against an unpredictable future.  Well structured, accessible Javascript will be easier to maintain by new people, and easier to upgrade and develop further.  Of course, it also makes developers think of the bigger usability picture, which is always a good thing and ought to result in easier to use Javascript elements for all site users.  But importantly, it’s something that ought to be encouraged.  The benefits to user experience are too big to ignore - who wouldn’t want a slicker, faster web site?  All you need to ensure is that it doesn’t lock some users out!

    Further Resources

  7. The Other Content Consideration: Accessible PDFs

    One other important constituency is of course PDF’s, Adobe’s popular document sharing file format.  Leaving aside content that’s embedded in the web page, PDF’s represent a significant part of what we make available on the web - from annual reports to white papers, brochures and maps.  I won’t dwell on the issues and solutions here because PDF’s are in fact extremely accessible, but you have to know how to author them properly.  As such you’ll find a comprehensive Accessibility ‘how to’ in Adobe’s product manuals and support forums.

Conclusion

To be blunt, the commercial case for Accessibility is a no-brainer.  By designing for it you extend your audience reach, attract more traffic, reduce your development and support costs, free yourself up for doing new things in the future, and, number one, you make your site more usable for EVERYBODY.  A developer (and a designer) working for Accessibility will guarantee you more sign ups, more purchases, and more happy users.  What more could you want!?

In terms of implementing Accessibility it’s important to firstly dispel a popular myth - that it’s expensive.  It’s not...or more importantly it doesn’t have to be.  If your technical team tells you it is then this ought to give you a clear message about their core capabilities.  Accessibility best practice is simple web development best practice.  Of all of the things we’ve reviewed here, we could drop the word Accessibility and you’d still have a best practice cook book for building great web sites.

So can we summarise best practice?  Sure.  To build a great web site that does all of the above (and serves a really important but often neglected audience - the LESS able), you need to do the following:

Separate your presentation from your content.  (Or should I say liberate it?)  This opens the door to a new way of developing which will save you time and money and give you more flexibility.  This means using cascading style sheets (CSS) in a strict but elegant way to ensure your site can grow gracefully (and it’ll also help in the bad times if your lead developer decides to walk out).

If you publish new content more than a couple of times a month then use a Content Management System (CMS).  It’ll help you separate the C from the P, and it’ll save you time and money in important production areas.  It’ll also keep you’re Accessibility initiatives (and your SEO initiatives) on track because you’ll be able to lock down what people can and can’t do in running your site.

Above all, employ the best web developers your money can buy.  If they’re worth their pay they’ll approach Accessibility not as a problem, but as part and parcel of doing a great job that they’re proud of.After all, designing for Accessibility is not rocket surgery, it’s good development practice and it makes plain commercial sense.

fujitsuoraclezendpostgresredhatdelldell