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.

Assistive Technology

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.

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.

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.

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.

Apply CSS to achieve the visual design.

Add javascript (and css) for enhanced functionality.

Add WAI-ARIA to make javascript widgets and ajax accessible

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.

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.

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.

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.

Support for WAI-ARIA varies in different browsers and screen readers.

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.

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.

Run automated tests

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.

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

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.

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.

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).

[…] 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 […]