Building a webpage with accessibility and interoperability in mind: part 1

I’m currently working on a rather large project at work, the BBC sport olympics website. Being one of the tech leads and a big advocate of accessibility and user experience I’ve been doing a lot of research and learning around making websites accessibility and trying to ensure that the site we deliver is accessible and usable by people with a wide range of abilities, devices and assistive technologies.

I’ve found there are lots of resources about web accessibility out there (and I’ll be creating a page for them here) – but not many to get web developers up to speed quickly and easily, especially with regards to javascript, so I thought I’d share some of my thoughts and findings.

In this first article I want to chat about about accessibility and interoperability and share a list of browser tests that can be used to identify potential problems. I’m planning a further articles to explain the list in more depth – and how to use it as an approach to building an accessible web page or component, as well as using it to test a page webpage that someone else has built.

The challenge of web development

As web developers we want to try and make sure that our web page and application works for as many people as possible – but are faced with the challenge of not knowing who is going to access our webpages or how. It’s wrong to assume that everyone is a sighted user using a mouse, the latest browser, a large monitor and a broadband connection.

Here are some of the things that are variable for each user:

Device

  • Desktop computer
  • Laptop
  • Tablet
  • Mobile phone
  • Television

Browser

  • old browsers
  • modern browsers
  • obscure browser (lynx, PS3)
  • brand new / future browser

Input device

Output device

  • Screen (and at what resolution?)
  • Speakers
  • Touch – refreshable Braille device
  • Printer

Connection (bandwidth and cost)

  • brandband
  • narrow band
  • wi-fi
  • 3g

Settings

  • font size
  • zoom
  • images on/off
  • javascript on/off
  • user stylesheet

Ability/Disability

  • Visual
  • Auditory
    • Full hearing
    • Partial hearing
    • Deafness
  • Motor
    • Able bodied
    • Traumatic Injuries
      • Loss or damage of limb(s)
      • Spinal cord injury
    • Diseases and Congenital Conditions
      • Cerebral palsy
      • Muscular dystrophy
      • Multiple sclerosis
      • Spina bifida
      • ALS (Lou Gehrig’s Disease)
      • Arthritis
      • Parkinson’s disease
      • Essential tremor
  • Cognitive
    • Experience
    • Deficits or difficulties
      • Memory
      • Problem-solving
      • Attention
      • Reading, linguistic, and verbal comprehension
      • Math comprehension
      • Visual comprehension

Assistive Technology

  • screen reader
  • screen magnification
  • speech recognition software
  • switch device

Furthermore, many of these are situational so can change for a user over time – e.g location, injury and ageing.

For example:

  • Eyesight, motor and cognitive abilities deteriorate with age.
  • A user may suffer a hand injury and be forced to use a keyboard rather than a mouse.
  • A sighted laptop user may have to use a 3g connection whilst commuting to work or traveling abroad and to improve the speed of accessing content and/or reduce cost they may choose to turn off images and/or css/javascript
  • A user may be forced to use an old browser at work.
  • A web server may fail to serve javascript files – or javascript code may contain a temporary bug – so a user is forced to experience a site without javascript

What is Interoperability and Web accessibility?

Interoperability

Interoperability is a property of a product or system, whose interfaces are completely understood, to work with other products or systems, present or future, without any restricted access or implementation.

wikipedia.org/wiki/Interoperability

Accessibility

Accessibility is a general term used to describe the degree to which a product, device, service, or environment is available to as many people as possible. Accessibility can be viewed as the “ability to access” and benefit from some system or entity. Accessibility is often used to focus on people with disabilities or special needs and their right of access to entities, often through use of assistive technology.

wikipedia.org/wiki/Accessibility

Web accessibility refers to the inclusive practice of making websites usable by people of all abilities and disabilities.

wikipedia.org/wiki/Web_accessibility

Universal design

Universal design refers to broad-spectrum ideas meant to produce buildings, products and environments that are inherently accessible to both people without disabilities and people with disabilities.

wikipedia.org/wiki/Web_accessibility

Not just a developers responsibility

As a developer there is a lot we can do to make something more or less accessible. There is, however, also a lot that is out of our control.

Some accessibility falls to the responsibility of the content producers – providing good labels, understandable text and helpful alt text for editorial images.

Some falls to the responsibility of the designers – color contrast, not relying on only color to convey information, not having auto updating content without the ability to turn it off. The order of content can also be affected by the design.

Some accessibility falls to the responsibility of the product owner – factoring in accessibility from the start of the project, allowing time for developers to learn and implement accessibility and including accessibility testing in the product timeline.

How does a developer build something that is both interoperable and accessible?

Use open web standards – html, css, javascript and WAI-ARIA – implement them using Progressive enhancement and test thoroughly.

  1. Add your content to a page in a logical reading order. To your content add the most appropriate (semantic) elements and attributes, add good heading structure and WAI-ARIA landmark roles. Add aria-labellby and aria-describedby where helpful.
  2. Apply CSS to achieve the visual design.
  3. Add javascript (and css) for enhanced functionality.
  4. Add WAI-ARIA to make javascript widgets and ajax accessible
  5. Test. Test. Test. See below for some suggested tests for developers. If possible also include an audit by an accessibility expert and user testing with disabled users.

Following steps 1 -4 does not ensure accessibility. It’s easy to introduce accessibility issues in each layer – which is why it’s so important to test your pages.

  1. In the html layer something as simple as duplicating links or not having alt text for images can reduce the accessibility of a page. As can incorrect heading structure – or badly marked up tables and forms. Don’t assume assistive technologies will understand new HTML5 elements.
  2. In the CSS layer common problems include accidentally hiding content from a screen reader by using display:none, or by keyboard focus not being visible.
  3. In the javascript layer common problems include inadequate keyboard control and/or keyboard traps, screen readers users not being informed of dynamically updated content and ‘widgets’ being coded in such a way that are unusable in screen readers.
  4. Support for WAI-ARIA varies in different browsers and screen readers.
  5. A developer following best practice AND testing a page is still unlikely to catch all accessibility issues – which is why getting accessibility user testing is so important if you can.

A common misconception, that I held until fairly recently, is the need to have a non-javascript version of something for it to be accessible. This used to be the case when screen readers didn’t support javascript – but as screen readers these days do support javasript and most screen reader users have it enabled implementing a non-javascript version falls into the realms of interoperability rather than accessibility. As Derek Featherstone explains in The Truth About JavaScript and Accessibility, from a web accessibility point of view, it’s more important to spend time making your javascript enhanced version accessible than building a separate non javascript version. Ideally you’ll implement something using progressive enhancement – and then do some testing and coding to ensure that the enhanced/javascript version is also fully accessible. But if you already have a product that turns out to be inaccessible it more important to make the enhanced javascript version accessible than building an accessible non-javascript version.

Another important thing to mention is that interoperability doesn’t mean spending lots of time trying to provide an identical experience in all/older browsers. It’s important that old browsers (such as IE6) can get the core content and core functionality (i.e read the text, submit forms and click links)- but not important the that visual design is identical or that enhanced functionality is available. As Nicholas Zakas explains in his recent Progressive enhancement 2.0 presentation – we should utilize the capabilities of a browser and be forward thinking, not wasting time trying to get old browsers to have an identical experience.

For a good summary on why it’s fine for a website to not look identical in all browsers see Where are my rounded corners

Why go the extra distance to achieve interoperability and accessibility?

  • professional obligation: looks amateur if what we have built doesn’t work for someone. Will be seen as buggy code.
  • moral obligation: the web is an enabling tool that can vastly improves the live of many disabled people – but only when web pages work with assistive technologies.
  • legal obligation: The Equality Act requires us by law to make websites accessible. If someone with a disability, such as sight loss, can’t access the information on your website then it could be seen as discrimination.

Browser based tests for accessibility and interoperability

How do you identify if what you have built is both interoperable and accessible? Here’s a list of suggested tests to quickly identify accessibility issues. Thank to Henny Swan and Hans Hillen for feedback and additions. Huge thanks to Hans and Steve Faulkner at The Paciello Group for a fantastic WAI-ARIA course and support desk and to Robin Christopherson at AbilityNet for a great screen reader course

In a browser – javascript off and css off – does everything make sense?

  • Is all core content available?
  • Is content in a logical reading order?
  • Has correct semantic markup been used?
  • Has a logical heading heirachy been used?
  • Are there any duplicate links or links without useful labels?
  • Check for a language specification on each page as well as individual parts where different languages are used
  • If iframes are used check they have meaningful titles to explain their purpose
  • Check wai-aria landmark roles are being used correctly

In a browser – javascript off and css on

  • Is all core content available?
  • Check for any broken functionality – e.g do all links work (Make sure that no links have <a href=”#”>)
  • Has progressive enhancement been used?
  • Check for display:none – has any content been hidden?
  • Load in a users stylesheet to confirm that your stylesheet is overrideable – e.g http://simplyaccessible.com/article/custom-styles-for-ios/

In a browser – javascript on and css on – use a keyboard instead of a mouse

  • Can you do everything effciently? Can you complete all actions?
  • Is it obvious what has focus? (use :focus as well as :hover)?
  • Have correct controls been used – e.g links, buttons and inputs?
  • Does the space bar work on all elements that have role=”button”?
  • Has focus and linear flow been managed properly? Make sure there aren’t any keyboard traps?
  • Forms – check for success case, error case, the ‘correction’ case
  • Make sure you are not killing other keyboard functionality
  • Can pop-ups/dialogs be closed with the escape key? Does focus return to item then opened it?
  • Is the virtual buffer updated when ajax is used to insert new content into the page – is the user notified of an update or focus set to the new content?

In a browser with javascript on – use a screenreader (NVDA, JAWS, VoiceOver)

  • Is all content and functionality accessible and usable?
  • Are tables accessible?
  • Are forms accessible?
  • Has WAI-ARIA been used to improve accessibility/usability?
  • Are users notified of new content or taken to it by setting focus to it?

In a browser – with css and javascript on – turn off all images

  • Is page still usable – checking for alt text and color contrast (e.g no white text on white a white background)

In a browser – with css and javascript on – increase the font size by +2.

  • Is text still readable?
  • Does the text or content truncate or overlay?
  • Are there huge empty spaces between form fields and labels?

In a browser – with css and javascript on – use ZOOM or a screen magnifier

  • Are all parts of the page still usable?

Use an old browser with javascript on and css on – e.g explorer 5

  • Is all core content available/usable?
  • We don’t want any javascript error – or broken layout – should work the same as no js and no css. We also don’t want a user to be offered links/buttons that don’t do anything etc

Use a tablet – e.g iPad

  • Does eveything work on a touch device?
  • With Voiceover on are all images labeled?
  • Are changes of state notified?

Use a Printer

  • Is core content readable?
  • Make sure width of content is not too wide for paper
  • Is a minimum number of pages printed out – don’t want to infuriate users by wasting paper!

Run automated tests

  • Run a colour contrast checker
  • validate HTML – http://validator.w3.org/nu/ (if your page is html5 and has microdata choose: HTML5 + SVG 1.1 + MathML 2.0 + RDFa 1.1 + Microdata)
  • Use a link checker

If you’ve got to the end of the post – thanks for reading! Took rather longer to write that I was expecting – but has hopefully been useful. If you have additions/amends to the browser tests please let me know and I’ll add them.

In a future post I’ll go into more details about the how’s and why’s of building a webpage that conforms to this list – and also some tools that can be used for testing them.

Related Resources

Articles

Presentations

Books

11 Responses to “Building a webpage with accessibility and interoperability in mind: part 1”

  1. Lynne Tamor says:

    This is a really nice summary! I was especially pleased to see the items relating to intellectual disability and what I call “information processing difficulty.” We’re just building our own website, but it will be addressing these same issues.

  2. Alistair Duggin says:

    Thanks Lynne. WebAim have an excellent article about Cognitive Disabilities. This is one of the areas of accessibility where interaction design visual, visual design and content play a huge role in making a web page accessible.

  3. Very useful blog.
    In the section on ‘why go the extra mile’ I think you should add financial: people with disabilities who can use your site will stay and they have buying power. You might also add that good accessibility can also improve Search Engine Optimisation (SOE).

    You might also want to look at the Seven Step documents produced by OneVoice http://www.onevoiceict.org/tools/tools .

    I will add your blog to the references section.

  4. Alistair Duggin says:

    Thanks Peter – good suggestions.

  5. Alistair Duggin says:

    Here’s IBM’s developer checklist:
    http://www-03.ibm.com/able/guidelines/web/accessweb.html

  6. Alistair Duggin says:

    This is the most comprehensive list I have seen so far:
    http://www.braillenet.org/accessibilite/referentiel-aw21-en/index.php

  7. [...] Henny Inspired by Al Duggin’s browser based tests for accessibility in his kick ass post building a web page with accessibility and interoperability in mind, I thought I’d put some tests together for mobile. This is intended as a guide you can use in [...]

  8. Henny says:

    Time and time again I point people to your ‘browser based tests for accessibility’ list; it’s such a great resource. We’re lucky to have you at the BBC :)

    Anyway, inspired by this I thought I’d put together a list of tests for mobile accessibility that can be used in day to day testing.

  9. [...] is not much activity here … anyway, I recently came across this article (inspired by this one), which makes a list of the different mobile accessibility tests available. It is not exhaustive, [...]

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>