There’s so much to think about when building a web site that it is easy to leave things out, or forget about important considerations. One of the most important of these is accessibility, an area of web design that can seem very daunting.
Web accessibility, in its purest form, is the practice of coding your web sites and applications so that users with disabilities can access all the content and functionality they provide. These users can break down into four main disability groups:
- Sight: Blindness, low-vision and colour blindness
- Hearing: Hard of hearing and deafness
- Mobility: Loss of limbs, paralysis, broken bones, Multiple sclerosis, Parkinsons and other illnesses
- Cognitive: this might include people with learning disabilities (such as Down’s Syndrome), people on the Autistic spectrum, with Asperger’s Syndrome, dyslexia, or other reading or memory difficulties.
While accessibility is about people with disabilities I like to think of it as at the core of a bigger picture: universal access. This covers areas of “accessibility” that are not traditionally associated with disabled people (although they can be too) but are of equal importance when designing web sites:
- Age: This isn’t just about your mum, grandfather or uncle who may struggle with age related illness or general deterioration. This is about you as well – no one plans on dying young right? In 10, 20, 30, 40 years time, you will be your own audience in this respect
- Mobile and devices: We consume the web everywhere on mobile phones, games consoles, TVs, kiosks and other devices that aren’t desktop or laptop computers
- Internationalisation and localisation: It’s a “World Wide Web” and, while you may not think so, users from all four corners of the globe could be reading your content
Where do you start?
This seems like an awful lot of diverse users to take into account on top of your existing customers and you may be thinking “how can I accommodate all these people?”. Well the good news is that if you use web standards and best practices to build your web sites and applictions, you will already be at least halfway there.
Many people also think of accessibility as an extra requirement that costs lots of extra money and must be bolted on to your web site, but this isn’t the case if you plan for accessibility form the start of the project. Accessibility should be built in and not bolted on to any website or web application build and if it is from the outset then you wont incur much, if any, additional cost. If anything you will get a better return on investment as more users will be able to access your content.
What follows are seven key areas that you need to think about when designing sites that are universally accessible.
Standards and Guidelines
Many standards are produced by the international standards body World Wide Web Consortium (W3C). This group also produces a number of guidelines that help you make the right decisions when creating accessible content:
- Web Content Accessibility Guidelines (WCAG): Guidance on how to make web content – text, images, forms, links, applications, audio and video – accessible to disabled users
- Mobile Web Best Practices (MWBP): Mobile web access is becoming increasingly mainstream as more powerful mobile browsers and handsets come onto the market. These best practices outline how best to produce content that is mobile ready
- Relationship between Mobile Web Best Practices and the Web Content Accessibility Guidelines: The cross over between issues and solutions relating to mobile web browsing and accessibility is significant. If you design with one group in mind you will go a long way to accommodating the other
All browsers and assistive technologies are built to understand web standards so if your web pages use them your website should be interoperable, future proofed and robust. Unfortunately there are some bad browsers that do not support web standards as well as they could yet still have a significant market share such as IE6 so this is not an absolute rule however designing with web standards will still take you a long way to universal access.
To better understand how web accessibility relies on the several components working together (browser, assitive technology and web content) see essential components of web accessibility from WAI.
Graceful Degradation and Progressive Enhancement
Graceful degradation and progressive enhancement are complementary principles, with one aiming for backward compatibility and the other forward compatibility.
Graceful degradation means building for the mainstream while adding in alternatives for less capable browsers, assistive technologies (software used by disabled users to access web content) or devices.
A good example of this is the use of
alt="Image description" – provides graceful degradation for browsers or users that can’t see images. More on that later.
Progressive enhancement is the concept of building a basic version of a site and adding enhancements on top for those browsers, assistive technologies and devices that can handle them. All site functionality should work perfectly without any bells and whistles. Progressive enhancement then detects support for more advanced features and adds them only if the browser, assistive technology or device supports them. If not the browser shouldn’t even let the user know they are there. The enhancements are there to improve user experience and usability but never be relied on for code functionality.
WAI-ARIA is also becoming a common tool of progressive enhancement. As this is a new specification browsers and assistive technologies have varying support for WAI-ARIA; while this is improving all the time, you still can’t rely on it across all browsers. Gez Lemon has written an excellent article an Introduction to WAI-ARIA.
Progressive enhancement is a great way of implementing new techniques and technologies on your site without compromising accessibility. It also shows an accessible site need never be boring and can be cutting edge.
Content and Presentation
At its most basic, separating content and presentation into separate HTML and CSS files is a form of progressive enhancement. It’s needed so that a user can view a plain page should their browser or assitive technology not be able to handle styled content. As such it protects the content and functionality within the source from being lost in styling.
Content should live in the HTML with all styling and presentation housed separately in a style-sheet. No content should appear in the CSS as users who are blind or have CSS disabled will not be able to access it. A good example background images and CSS as well as CSS generated content – you should ensure these are for decoration only. Any text should appear within the HTML.
Housing presentation in the CSS also allows you to target styling according to the type of media you are using. Media types and media queries allow you to tailor your single source of content so that it renders well on different screen sizes with varying support for colour, fonts and styles.
By separating presentation into CSS you also give flexibility back to the users so they can customise pages to better suite their needs via the browser. Many low-vision users like to read white text on black, scale text up or choose bespoke background colours.
Having a good page structure is closely linked to separating content from presentation. Visually, we rely on headings, lists, titles and suchlike to easily understand text and scan the page. If headings and lists were styled only using CSS or old-school HTML such as font tags we would lose a lot of the semantic information of the page; information that is essential for screen reader users and voice input users (who use voice commands to navigate headings).
Headings should be coded using
<H6>. Ideally one
<h1> should be used per page and the headings should flow in a logical order – much like the contents overview of a book – and avoid skipping levels. Don’t be shy about using headings to break up long and complex forms as well.
Lists should also me marked up using
<ul>, <ol>, <li>, <dl> and
<dt>. They can be styled later for aesthetics but having them coded correctly means a screen reader can identify a list as a list and pinpoint what number list item you are on.
Paragraphs should be coded using
<p> elements, one for each paragraph! DON’T do things like using
and then adding spacing later on, or using a single
<p> and then breaking the different paragraphs with
<br> tags (line breaks). There is one right way to mark up paragraphs, and loads of wrong ways!
The example below shows the importance of using headings and list elements to code headed sections and lists:
<h2>Party checklist</h2> <ol> <li>Food.</li> <li>Drink.</li> <li>Invitations.</li> <li>Music.</li> <li>Venue.</li> </ol>
This code then renders as follows:
When a screen reader encounters the above list it will know to say “Heading level 2: party checklist” followed by “List of five items. List item one: Food”. If the heading and list items were not there a screen reader would just read the text which is not as helpful.
Continued in the next issue of Scrunchup