Creating Accessible Online Resources – Part 1: Laws and Principles

Introduction

Tim Berners-Lee said, “The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” (1997) This is something that’s driven the development of official web technologies since their infancy. Berners-Lee wanted to create a means to share information with everyone in the world without bias. Over the years, the Web he spoke of has developed into a massive pool of information that we call The Internet and it’s not just serving plain web pages to people any more.

This is important to understand because it’s at the heart of the new laws that come into force starting in September 2019. The UK’s Equality Act of 2010 consolidated and updated several laws regarding equality of access to various services without prejudice to age, gender, disability, religious beliefs or sexual orientation. In September 2018, ‘The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations’ further updated the Equality Act to require that all public sector bodies make their web sites and electronic documents reflect the rights provided by the Act. This means making sure that people with disabilities are not disadvantaged in their (in our case) educations, simply due to their disability.

The World Wide Web Consortium (W3C, the body that develops and recommends web standards) has created a set of accessibility guidelines for web sites that I make use of on the Faculty’s web site, but these new laws mean that any documents produced by you for inclusion on any web platform must also meet a minimum set of requirements. The guidelines produced by the W3C are of sufficnet robustness that we can extrapolate from them and use them in the production of any online resources, whether they’re based on HTML or not.

The basic tenets of the requirements that we shall be looking at are that you cannot – either deliberately or inadvertantly – create a web-based resource that will disadvantage someone due to any disability they may have. It is the document creator that is responsible for the resource meeting accessibility standards. This means you need to know what the recommendations are and how they should be applied.

Linguistic Conventions Used in this Guidance

Please feel free to skip this section if you already know terms like right-click, ribbon, URL, hyperlink/link and understand the difference between paragraph formatting and style formatting.

When I talk about right-clicking, and I do that a lot in this document, I refer to bringing up an object’s contextual menu. There are a lot of ways to do this, depending on what sort of operating system you’re using and what kind of mouse or keyboard you have. On a Mac, you can press down the control key on your keyboard and then click on an item. You can also use a two-finger-tap on many trackpads (Mac or PC) or the Menu button on your Windows keyboard, amongst many other ways. I’ve decided that for brevity, I’m going to say ‘right-click’, but what I mean is: any way you normally bring up a contextual menu to select items on it.

Ribbon specifically refers to Microsoft Office’s graphical menu system dating from Microsoft Office 2010 and newer. Since most of the people I work with every day use Office, much of what I talk about is specific to how to do things in that system.

A URL is a Uniform Resource Locator – a web site address. A link or hyperlink is the clickable text that goes to a URL. This is an important distinction – the hyperlink may look the same as the URL, (e.g. https://www.google.co.uk/ ) but it’s not.

A style or style sheet is the template that gives a document a standardised look and feel. Every level of heading looks the same and every block of standard text is the same, etc. Having a style sheet means that it’s easy for everyone to figure out how your documents are laid out; how they work.

Paragraph formatting versus style formatting is similar to the URL/hyperlink definition above. A paragraph is only a small part of a document and can be formatted on its own without changing the style formatting of the whole document. Just be aware, when you only change a single paragraph’s formatting (you do this by selecting the paragraph and simply going to the ‘Format Paragraph’ dialogue box), you run the risk of your changes not being applied to every other paragraph you write. If the change you want to make should be universal, you must change it in the document’s style template.

What is Accessibility and Why is it Important?

The simplest answer to this, in context, is: Accessibility means making your electronic resources available to and usable by as many people as possible.

Why is it important? First, it’s the law. All new and revised documents available online must conform to standards by September of 2019. All ‘historic’ documents that remain online must be updated by September 2020.

As important as the laws are, in my view, creating accessible documents and resources is more about extending courtesy to others. We may not be aware that a student or colleague has need of accessibility tools for many reasons:

  • They may have a disability that is all but invisible.
  • They may not yet have a diagnosed disability.
  • They may be embarrassed to talk about a disability they have.
  • They may have asked for help, but their support documents haven’t reached us yet.
  • Their disability may not usually cause any issues (but just because it hasn’t yet, doesn’t mean it won’t!)

Building accessibility into your standard working practice means that people won’t have to make a special effort – any more than they usually would – to benefit from your resource. The requirements and the tools to meet these standards are easy to quantify and understand using an acronym called POUR, which has been used for many years in web development circles.

POUR (Perceivable, Operable, Understandable, Robust)

One of the most difficult parts of understanding accessibility is getting past our own inherent biases. We human beings almost always use ourselves as a reference point when we think about how others might perceive what we’re doing or how they might view or use output we produce. But when we consider the vast number of people we provide information to as individuals, much less as institutions, it’s important to bear in mind things like the fact that 1 in 12 men have a colour vision deficiency (in women, it’s 1 in 200). The likelihood that someone in one of your lectures or seminars has a CVD is quite high. Someone who has an Autism Spectrum Disorder (around 1 in 100 people in the UK) may have a sensory processing issue that means they have difficulty with audio or video in a classroom setting (an estimated 70% of people with an ASD are also diagnosed with sensory processing issues). 1 in an average of 8 people has some form of dyslexia. POUR is a way to attempt to get outside your own head in a methodical manner and consider how you might make your resource usable by the greatest number of people.

Perceivable: Users must be able to perceive the content; it cannot be hidden to all of their senses.

Operable: Users must be able to successfully navigate the resource using their preferred methods.

Understandable: Users must be able to understand the content and how to use the interface.

Robust: Your resource should be standards-compliant and users should be able to choose their manner of accessing it.

Keeping it simple is almost always the safest way satisfy these requirements.

Examples

Perceivable

Users must be able to perceive the content; it cannot be hidden to all of their senses.

The majority of users perceive web content mainly through their eyes and ears, but for a significant number of people, this is not easy or even possible. You should make sure that you have alternative methods for students to be able to get key information. This means bearing in mind users who have partial hearing or are Deaf, who are partially-sighted or Blind, and those who may have other issues that mean they cannot perceive your resource without adaptation.

Example

Scenario: As part of the talk, the lecturer shows a video clip that is important to the topic. The video clip does not have subtitles or a transcript and they expect the students to discuss the clip afterwards.

How might student who is deaf or hard of hearing be disadvantaged if the clip isn’t available for them to access before the lecture? How might they be further disadvantaged in contributing to a discussion for which they haven’t been able to fully perceive the central element?

Takeaway Points

Where possible, you should provide alternative methods to access the important data in your resource. This may mean providing the information ahead of time or providing a transcript or subtitles for audio and video content.

Operable

Users must be able to successfully navigate the resource using their preferred methods.

Most adaptive methods of accessing resources on the web are the equivalent of mouse clicks and keyboard shortcuts. It may be an alternative mouse or keyboard (e.g. sip-n-puff, mouth stick, single-hand keyboard, etc), but generally the same principles apply. The thing to remember is that someone with a disability may use one of these methods and may not be able to use the other. Your resource should take both types of access into account individually.

Example

Scenario: A lecturer creates a nicely formatted handout that contains no images. They carefully bold each title and change the font size to 16 so it is noticeably larger than the text on the rest of the page and stands out visually. They use a size 12 sans serif font because they know it’s easier for people with some types of dyslexia to read sans-serif fonts.

How might a a student who is visually impaired or blind be disadvantaged by this document? How might a student with dyslexia who uses a screen reader be disadvantaged?

Takeaway Points

Despite the extra time and attention taken by the lecturer, this document would still be problematic. It has no headers or any other way for the student’s screen reader to skip from section to section. They may need to use a combination of sight and manual dexterity to get to the section they want and that may not be possible.

Understandable

Users must be able to understand the content and how to use the interface.

There are two parts to this: functionality and meaning. I’m going to focus on the latter, but it’s worth always being aware of your audience and taking the former into account. For example, writing resources for university students who are studying your field will need a different level of language than writing a how-to guide for the general public. I tend to think of functionality as the user-interface side of things. This is a high level way of saying: be consistent so that you don’t confuse people.

Example

Scenario: You create a handout which uses a ‘Red/Amber/Green’ system to help students think about the material they’re reading in an effort to aid critical thinking skills.

What sorts of disadvantages might this give students with various disabilities if you don’t provide an alternative method of pointing out these critical thinking points?

Takeaway Points

1 in 12 men have a colour vision deficiency (as do 1 in 200 women). This means that the likelihood that at least one student in one of your lectures or seminars has CVD is very high. In this case, as well, if you don’t add alternative or descriptive text to your images, it could mean they are all but imperceptible to someone using a screen reader. Never use colour only as a means of communicating information.

Robust

Your resource should be standards-compliant and users should be able to choose their manner of accessing it.

In order to create resources that are compatible with future technologies, we need to use current technologies the way they’re designed to be used. This often means using the most common commercial systems available and using the accessibility tools already built in to them. Future software designers will then have a standard they can work from and will know how to tell computers to interpret the content. In some cases, it may take a little more time and effort to create resources that meet the standards required, but in the long run it will produce more reliable output and will not only increase the chances that the content is accessible to people with disabilities right now, but also allow your content to be digitally viable longer, overall.

This section is less about anything you need to do, specifically, to make your resource accessible, but more about what technologies you use to do it. As I said right at the beginning, keeping it simple is almost always the best route to take. Use standard word processors that produce output like Microsoft Word docx files and RTF files where you can. When you must scan something, try to make sure that you either scan to ‘searchable PDF’ or to a Word document. The photocopiers in the first floor copy room can be made to do both sorts of scanning and we’re very happy to show you how or you can have a look at our blog post on how to scan to searchable PDF.