1. Introduction

Over 11 million people in the UK have a physical, visual, audio, speech, or cognitive disability. By the age of 51, many of us gradually lose the ability to focus on nearby objects. Cognitive disabilities are often undiagnosed. AGE UK estimates that 7% of people over 65 will have late onset dementia and by 2051 the number of people with dementia in the UK will rise to over two million. Anxiety and attention deficit disorders are often hidden disabilities. ADHD Action estimates that 1.5 million adults in the UK have ADHD but only a small proportion are diagnosed.

Nearly one in five people had some form of disability in England and Wales

Office for National Statistics

There are many temporary disabilities like frozen shoulders and repetitive strain injuries that limited the use of a mouse or keyboard. Also, situational use effects everyone like using a mobile phone in bright sunlight, quiet or busy environments to access video content and low bandwidth/low data.

It is vital that websites are accessible and fit for purpose. This means that they are designed and developed so anyone can use them regardless of disability. The internet was originally built to be accessible, so what is the problem? It is us, we put barriers in the way like:

• A complex design that overrides basic HTML
• A website editor that does not provide accessible alternatives
• Brand colours that do not work when used as text
• Not checking what people are putting on your site
• Animated or interactive content
• Videos with no captions or transcripts
• Overcomplicated menus and page layouts

The rules, should we care?

In 1997 the W3C Consortium, an international body of 400 organisations that governs web standards, set up the Web Content Accessibility Guidelines, shortened to WCAG. There have been several versions since, the latest is 2.1. These guidelines state websites must:

• Provide ways for everyone to access content
• Enable people to browse websites using a keyboard or a screen reader
• Ensure text is readable and content makes sense
• Be compatible across all devices such as desktop and mobile

Each guideline has a list of criteria which can be tested which helps us ensure that websites are fit for purpose. The success criteria have three levels: A, AA and AAA; where A is the easiest to achieve and AAA the hardest. In the UK the standard has been set at AA for all public bodies or organisations that receive more than 50% public funding. Even if you are not publicly funded then the Equality Act 2010 states it is a legal requirement not to discriminate against people based on disabilities and requires website owners to provide an equal experience to all users.

However, as heritage organisations, we need to look beyond the legal compliance for accessible websites. In our sector, most of our work has access as a core value. Our sector is a driving force for equality, inclusion and accessibility.

How do people use websites?

In this practical resource, there is not time to go into depth on how people with disabilities use websites. However, it is highly recommended that you visit the videos published by W3C to find out more about assistive technologies and the difficulties people face. There are also stories of people with disabilities.

The top three barriers

The biggest accessibility issues are colour contrasts, image descriptions and form labels. If you solve these then you are a long way to making your website accessible. Jump to these sections first if you want to quickly improve your accessibility.

If you don’t have a lot of time, you can focus on the following priority issues. WebAIM, who provide one of the best automated checking tools, annually report on the accessibility issues found in the top one million home pages.

Most common types of accessibility failures

WCAG Failure Type	% of home pages in February 2021	% of home pages in February 2020	% of home pages in February 2019
Low contrast text	86.4%	86.3%	85.3%
Missing alternative text for images	60.6%	66.0%	68.0%
Missing form input labels	54.4%	53.8%	52.8%
Empty links	51.3%	59.9%	58.1%
Missing document language	28.9%	28.0%	33.1%
Empty buttons	26.9%	28.7%	25.0%

Published by WebAIM

 

2. A website accessibility audit

2.1 Introduction

Doing your own audit and fixing issues may seem overwhelming, but hopefully following the steps below will make this less scary! The WCAG guidelines can seem daunting, so hopefully this resource will make things more user-friendly.

Select a sample of between 10 – 15 web pages from your site you would like to test. This sample number is based on a report by Velleman and van der Geest. If you have a small site, then 5 – 10 should be sufficient. Choose a good representation of your content, like homepage, events and news, plus also any pages with ‘functionality’ like shopping carts, logins, online booking and newsletter signups.

Many organisations will assess WCAG compliance by using an automated checker tool such as Webaim’s WAVE. It is suggested that you limit your use of this because:

• It may be unclear to you what the errors are in the report. It is better to do you own audit first so you can understand what you are looking for.
• These automated tools miss out over 50% of the accessibility issues.

Follow each section and make notes as you go:

2.2 Page structure

This section looks at the ‘generic’ structure of your web pages, the titles, sections and headings they contain.

a. Page title

Your page titles allow people with visual disabilities to have multiple tabs open in their browsers. For people with cognitive disabilities, its useful to have an easily recognisable title at the top. The title is also used in your search engine results.

On your browser tab, check the page title. For example, the image below shows the title ‘Digital engagement and activities’ on the browser tab.

Ensure your page titles are meaningful and under 60 characters. If you need to change them, in most web editors, the page title is the page name. In WordPress you would change it by editing the page and changing the title.

b. Page landmarks

Your web pages will be split into regions or landmarks such as a header with a navigation menu, main content and a footer. It is important that these sections are identified in the code. To check this, you can install a browser extension or add-on in your browser of choice. Visit Landmarks and choose your browser. Here are some links to help you add extensions:

For Chrome: https://support.google.com/chrome_webstore/answer/2664769?hl=en-GB

Firefox: https://support.mozilla.org/en-US/kb/find-and-install-add-ons-firefox-android

Edge: https://support.microsoft.com/en-us/microsoft-edge/find-add-or-remove-extensions-in-microsoft-edge-f3522273-d067-7435-6a9d-fdb99213e9a8

Safari: https://support.apple.com/en-gb/HT203051

Activate the Landmarks extension on your browser and view each sample page. You will see a panel like this which shows each section of the page such as banner, navigation, main and footer:

If you select a landmark such as ‘main’ that will highlight the area on the web page as shown here:

 

 

Look for these specific landmarks: header, navigation, main and footer. If you cannot locate them, you may need to ask a web developer for help. Most common web builders such as WordPress, Wix and SquareSpace should put them in by default.

c. Headings

Every web page has a sequence of headings. If you think of a web page as a book then the book title would be the H1 heading tag, each chapter are H2, sections within each chapter H3 and so on. You would only have one H1 per page and then the others follow in a hierarchy. A web page could have a heading structure like the following. A shows a correct sequence, B incorrect.

A. correct
<h1>Page heading</h1>
paragraph(s)
<h2>First section</h2>
paragraph(s)
<h3>First section’s subsection</h3>
paragraph(s)
<h2>Second section</h2>
paragraph(s)

B. incorrect
<h1>Page heading</h1>
paragraph(s)
<h2>First section</h2>
paragraph(s)
<h6>First section’s subsection</h6>
paragraph(s)
<h2>Second section</h2>
paragraph(s)
<h1>Another heading</h1>

You can test your headings using another browser extension called ‘HeadingsMap’

Firefox: https://addons.mozilla.org/en-GB/firefox/addon/headingsmap/

Chrome: https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en

Go to the web pages you are testing and activate the HeadingsMap (again check your browser instructions on how to do this). This will open a panel shown below listing all the headings on your page. If any heading is out of sequence this will be highlighted

It is common to have headings out of sequence as they are often used by content editors to get the required font size. Here is an example on the AMA site (which was quickly corrected when we found it) where the ‘on sale now’ was added using an <h4> title. This should have been an <h3> or another text format.

d. Page consistency

It is important that all menus, buttons and icons remain consistent across your site. Check that different pages do not have different menus, buttons or noticeable different designs.

 

2.3 Moving around

This section looks at how your users move around your website.

a. Menus or navigation

You need to give users two or more ways to locate a web page. Pages that are part of ‘processes’ such as logins, carts, newsletter signups are exempt from the criteria. It would be unlikely to have less than two, but check that each of your sample pages has at least two of these:

• Search
• Menu or navigation
• A table of contents linking to sections within the page
• A site map showing all pages on the website
• Links within the text content

b. Location

This is an AAA requirement so not vital but highly recommended if you want to help people with cognitive disabilities use your site. Users need to be shown their location within a set of web pages. For example, if a user clicks ‘about us’ then ‘volunteer’ which is a sub-page within ‘about us’, they need to be shown visually where they are. There are three options:

• Breadcrumb trail. At the top of the page, show where the user is, for example, Home > About us > Volunteer
• A highlighted menu item in your navigation. In this case ‘About us’ would be highlighted on the menu to show the user they are in that section
• A site map link visible on every page

c. Text links

Are all your text links descriptive and can they be read out of context? Check you don’t have pages with links like ‘read more’, ‘click here’ and ‘more details’. Are all your links unique? No multiple ‘book nows’ on a page for example.

d. Keyboard only

It’s vital that your website is accessible without a mouse. Try to move around the pages in your site using only the tab, arrow keys and enter. How far can you get? Here is what to look for:

Skip to content link

The first time you click ‘tab’, does a ‘skip to content’ link appear? This enables you to jump directly to the page content rather than having to tab through all the menus.

Focus state

All this means is that you can see where you are on the page when you are using a keyboard. You can clearly see which links you are on. A focus state can be a line around a link or a change in the background contrast. Tab through your site and check every link changes in some way. If you do not have focus states it is not a big issue – a couple of lines of code that a web developer can add.

No context change on focus

This means that when you highlight a link or a menu item using the keyboard or a mouse but you do not click it, the following should not happen:

• Immediately goes to a new page
• Opens a new tab of window
• Opens an expanded area on the same page
• Opens a dialog message

Dropdown menus

This is slightly contentious issue and connected with the ‘no context change on focus’. Some people say that dropdown menus are inaccessible as they change the context on focus, that is open the sub menu. To be on the safe side it is better that menu dropdowns are user activated (have a look at the menu on this site). A keyboard user can tab to the menu and then needs to press the ‘enter’ key to activate the dropdown menu. Once in the menu they can tab again or press ‘esc’ to exit the sub menu. If you have menus that automatically open then you may want to ask a web developer to replace your menu code.

Keyboard traps

A good example of a keyboard trap is a dropdown menu you cannot get out of using a keyboard. Other common traps are things like popup calendars, the user can get in them using a keyboard but can never exit.

Drag and drop

If you have any drag and drop functionality on your site, check that cut and paste (using shortcut keys, for example, CTRL + V on Windows) also works.

 

2.4 Colours and colour contrast

A common accessibility failure is poor contrast text. This is because of the text colour or the background the text is on.

There are rules on the level of contrast allowed on web pages. The easiest way to find colour contrast issues is to use WebAIM’s Web Accessibility Evaluation Tool (WAVE). Enter your web page in the ‘web page address’ field. Check how many ‘contrast errors’ you have. This can be found in the top right of the summary tab:

You can find the contrast errors on the page by looking for the ‘low contrast’ errors like shown here:

 

If you’re using a keyboard please refer to WebAIMs accessibility tips.

The WCAG guidelines recommend a colour contrast of 4.5:1 for normal text size and 3:1 on large text. A useful tool is WebAIM’s Contrast Checker. Enter your text colour (foreground) and the background colour. If the contrast ratio is greater than 4.5:1 you will pass. This tool offers a useful slider so you can gradually darken your text colour until the ratio passes.

Use of colours

Check that you do not use colours to distinguish between things on your website. An example of this would be colour coding different sections or use colour to distinguish different types of data such as prices (without pound signs).

Another great tool is the High Contrast extention. This is for Chrome, you can find similar plugins or extensions for other browsers. This gives a control panel that enables you to check out your site in greyscale, inverted colour and yellow on black. If you find you have issues reading text in greyscale you do need to check your colour contrasts.

 

2.5 Images, audio, video and animations

a. Images

Check that your images have alternative text or ‘alt’ text. This is a short description of the image. Do not use more than 100 characters as anything over may be cut off by screen readers. The alt text can usually be easily added on your web editor. Check that your image adds to the content, if its purely decorative leave the alt tag blank. If the image is used as a button, then the alt text needs to describe the purpose of the link rather than what the button looks like.

It’s also good to check on your image sizes. Large images take longer to download and can make your site significantly less user friendly, particular for people who have limited mobile data allowances. Run a pagespeed insights test on your sample web pages. Enter the web page URL and click ‘analyze’.

There’s a lot going on in this report. If you have a fail then you may want to investigate why this is the case with a web developer. In this instance you are looking for image issues, scroll down to the ‘opportunites’ report and check for the line ‘serve images in next-gen formats’ and open this up. This will list any images that need replacing because of their file size.

A good rule is to ensure all your images are JPEG rather than PNG and are resized to less that 2000px wide. That will decrease the image size. The insights report will suggest you use image formats such as AVIF or WebP but these are not universally supported yet so best avoided for the time being.

b. Complex images such as graphs, charts, diagrams and infographics

It is important to put a longer description with complex images to describe the information they portray. There are many code-based techniques to adding a description, however the easiest way is to use the existing alt text. In the alt text refer to a section of the page that describes the image. You could describe the image as part of the text or in a separate area at the bottom. Here is an example:

In the alt text for this image, you would put “Pie chart showing sources of accessibility issues. Described in the section titled Accessibility Issues”

So, this refers users to the section in your text that you explain the pie chart. Be careful to keep below a 100 character limit on this alt text.

c. Audio only

If you have audio on your website such as a podcast episode you will need to add a text transcript, indicating who is speaking and any non-verbal sound effects. There are online services to help with this such as Rev and GoTranscript that are reasonable at around £1.20 per minute of audio.

d. Video only

It is rare to have videos with no audio, but if you do you will need to add audio description to the video. See below for ways to do this. WCAG criteria state that a text equivalent such as a transcript is not needed, however you may wish to also include this as it will improve search engine optimisation.

e. Video and audio

Digiday report that 85% of Facebook videos are played muted which indicates many of your users really need captions. Captions are required for WCAG criteria and they need to be more than subtitles and include non-speech sounds such as music or sound effects. You can use services like Rev and GoTranscript to create a transcript file. This file can be uploaded to a provider such as YouTube who can auto-sync your text to the video audio to create captions. It is also great to have the transcript running alongside the video too.

If there are portions of your video that run without audio you may also need to include audio description. Shut your eyes when you play your video, can you follow using the video audio alone? To add audio description the quickest way is to use a service like VEED.IO. Upload your video and add a new audio layer. You could record this yourself as the video plays. When you are finished you have a new video to publish alongside your existing video.

f. Animations

If you have a piece of animated content, then you can treat that like a video and add captions and audio-description if necessary.

 

2.6 Putting your user in control

Many people with cognitive disabilities have difficulties concentrating and find moving content in particular distracting.

a. Audio and video

All audio and video need to offer a pause/play or stop control if it plays for more than 5 seconds. Many people with cognitive disabilities struggle with videos playing whilst they are trying to read other content on the screen.

b. Moving, blinking and scrolling content

Many websites use carousels particularly on the home page. This is a rotating gallery of images and text to inform users about the most important things on the website or news. You may also have smaller rotating sections or sliders on your pages. These are not good for people with cognitive disabilities. If you have any content that starts automatically and lasts more than five seconds you need to offer ways to pause/play and stop. If that is not possible, then perhaps a way to hide the content.

If you have any animated page content like bouncing buttons, flying in text areas or scrolling parallax images; then you may want to consider disabling the animation. This is a AAA level criteria so there is no legal requirement but out of consideration for your users it may be a good step to take.

c. Alert messages

If you have alert messages for news, signups or adverts then it is good to offer users a way to turn these off. This is again a AAA requirement so not essential but will make your website more user friendly.

d. Timed interactions (AAA level)

Giving users a time limit to complete purchases or fill in forms can cause issues for people with visual, cognitive and physical disabilities. If you can, allow users to complete without a time limit. If you have long forms then having a way for users to save them (or you even auto-save) would be great.

e. Touch targets (AAA level)

Do not confine your testing to your desktop. On a mobile device check the size of your buttons. Buttons should be a minimum of 1.6cm wide, about the width of an adult finger. Also check there is clearance around the button and no other buttons or links to close. A text link needs to be at least 1.2cm wide. The button width rule often applies to icons, particularly little info icons which are quite common.

 

2.7 Tables

Check that your web pages do not use tables as a way to lay out content. It is common to do this in a Word Doc but creates inaccessible content on a web page.

If you use a table, it needs to contain data (text or numbers) and have a caption and defined headers. Without headers, a screen reader will not know what is a column or row header and what is the data. If you are okay editing the HTML a little, do the following:

Here is the table:

Name	Favourite colour
Judy Bench	Yellow
Denzel Dryington	Red

In the code this looks like:

<table>
<tr>
<td>Name</td>
<td>Favourite colour</td>
</tr>

<tr>
<td>Judy Bench</td>
<td>Yellow</td>

</tr>

<tr>

<td>Denzel Dryington</td>
<td>Red</td>
</tr>

</table>

Make the following changes putting in a new caption after the <table> tag and changing the first <td> tags to <th>:

<table>

<caption>My team’s favourite colours</caption>
<tr>
<th>Name</th>
<th>Favourite colour</th>
</tr>

<tr>
<td>Judy Bench</td>
<td>Yellow</td>

</tr>

<tr>

<td>Denzel Dryington</td>
<td>Red</td>
</tr>

</table>

 

2.8 Text

a. Literacy level

Check your copy has a reading level of lower Secondary school. A great tool to do this is the Hemmingway App. Copy and paste samples of your text directly into the app to get helpful hints. Aim for a score of 8. Avoid subjective language such as ‘easy’ or ‘simple’, what you think is easy may not be for your users. Avoid abbreviations (you can include BBC and NHS), metaphors (I’m drowning in paperwork), colloqualisms such as slang (‘gonna’), phrases (‘it’s a red letter day’) or aphorisms (‘actions speak louder than words’).

b. Reading order

Check your content has a clear running order, especially on mobile devices. If content has been put in multiple columns across the page like this:

On a mobile phone it would look like this:

c. Readability

Run these checks to achieve the WCAG 2.1 AA criteria:

Font

There is not a best typeface to use. Many people argue that san serif fonts are better, but any familiar easy-to-read font is fine. The British Dyslexia Association give some useful tips on selecting a font and suggest san serif such as Arial or Verdana.

Font size

Standard text size is 16px (12pt or 1em) or above.

Italics and bold

Avoid using italics (may be missed by assistive technology) and bold if it used to infer more importance.

Line spacing

Line spacing is 1.5 times your text size, so if your text is 16px, line spacing is 24px.

This line spacing would fail the criteria for example:

Text resizing

Check that you can increase the text size to 200% using the browser controls without the page having to scroll horizontally.

Reflow

Reduce the width of your browser window as small as you can. Check the page does not require both vertical and horizontal scrolling.

 

2.9 Forms

Forms are difficult to get right so please do ask a web developer for help if you need it.

a. Clear instructions

Put clear instructions next to each field to help the user. Be careful as too much information can be as confusing as too little.

b. Labels

The quickest way to check form labels is to use WebAIM’s WAVE tool. Add your web page URL and check the report. Form errors will show as ‘Errors’:

 

Have a look at the detail tab and look for ‘missing form label’

This indicates that there is a form input box without a label. It is unlikely you will find this error but if you do it is a serious accessibility issue. If you do not want to get involved with code then ask a web developer to fix this for you, otherwise read on.

Take a form that asks for an email address:

Email:

The code looks like this:

Name: <input type=”text” name=”email” />

There is no connected label element. To correct this put in a label element:

<label for=”email”>Email: </label><input type=”text” name=”email” />

c. Required fields

For required fields avoid using something like ‘the fields in red are required’, instead ‘marked with an asterisk’.

d. Add autocomplete if you can

If you can, ask for autocompleting fields on your forms. The most common one is a postcode address lookup to automatically insert an address.

e. Allow people to fix mistakes

If the user fills the form in incorrectly put in a helpful message to show how they can correct it. Put validation messages as close as possible to the fields in question.

f. Allow people to review before they complete

If you can, give users a chance to check forms before finally submitting. This is highly recommended for any forms with financial transactions

 

2.10 Your audit – ways forward

Hopefully this accessibility audit will give you a list of issues that you need to address on your site. Accept that you probably will not be able to fix everything quickly and that you may need to budget for some developer assistance. There are a lot of issues you can deal with yourself, things like images alternative descriptions and video captions. However, there may be more complicated form, menu and layout issues that you need some extra work. You may conclude that a new website is needed (please refer to the resource Where do I start when building a new website) or that you need to replace your content management system or design. These are discussed in more detail below.

In the meantime, you can now publish an accessibility statement based on the audit you have done. Have a look at the accessibility statement on the British Museum website. This clearly states what works but also what does not. Notice how the British Museum lists the content that does not comply with the regulations. You do not need to fix everything at once if you can tell your users where the issues are. Also provide a named accessibility contact such as access@your-company.org.uk . This could be you if you have done this audit. Avoid it being a general email address as the recipient may not understand the nature of the request.

 

3. Audience journeys and user experience

So far, we have looked in detail at accessibility, however there are other ways to make your website more user friendly. By identifying your online audience and looking at your audience journeys you can find areas to make improvements.

Please look at these resources to find your online audience and their journeys: How to identify the key audience journeys on your website. Also, the resources How can analytics help me find out who my audiences are and How do I get visitor feedback online to improve what we do.

This research will help you identify changes you need to make such as:

• Do I need to add in more landing pages for specific audience types?
• Do I need to change my menu – are you users getting lost?
• Should I rewrite pages and put in prominent call to action buttons?
• Put in more guidance notes on online booking to avoid the high exit rate

 

4. Do I need a new website or content management system?

Starting again with a new website to fix accessibility is a huge decision. After following the quick accessibility audit in this resource, you could decide to improve your current website or replace it. If you need help with starting a new website please see the resource Where do I start when building a new website for my heritage organisation?

A big reason for replacing the whole site is to have a new content management system (CMS). You may find your current CMS is just not fit for purpose. The table below shows a large difference between popular content management systems. Squarespace, for example, performs poorly on accessibility compared to systems like Drupal or WordPress.

 

Average accessibility errors on content management systems

CMS	Average errors	% difference
Squarespace	19.7	−61.6%
Drupal	51.0	−0.7%
WordPress with Elementor	53.6	+4.3%
WordPress with Gutenberg or classic editor	56/6	+10.1%

 

If you are currently using WordPress, you may be interested to look at the difference in accessibility ratings of the different editors. Accessibility is determined by the page editor you use. Editors such as Elementor, Divi or WP Bakery give you a lot of control over page content, However, their usefulness to you in being a great editor can cause significant accessibility issues by putting a lot of unneeded code on the page. You may want to consider switching to Gutenberg, the WordPress in-built editor. Gutenberg has had a lot of bad press over the years, but recently has shown marked improvement and offers the same functionality as the other editors.

 

5. Accessibility widgets

Many commercial accessibility widgets are available. These provide an embed code to insert an accessibility overlay on your website. This gives you a prominent accessibility button that activates a menu of useful accessibility tools such as text zoom and contrast change. Many people hope these tools will then offer all the WCAG 2.1 functionality required without having to do the work on their own website.

This type of quick fix is very tempting. Search for people like Anna Cook and Shell Little who argue that this type of functionality is insulting to people with disabilities. It would be good to tell you more about this, but some companies are taking legal action against anyone who criticises them. Do your own research before buying anything.

 

6. Conclusion

Hopefully this resource has given you a practical tool to conduct an audit of your site and identify areas where you can improve. Having a user friendly and accessible website should be at the top of the agenda for many heritage organisations. Unfortunately, this is not the case, mainly because it is not given priority by senior management and trustees. Ask for your organisation’s accessibility policy – does one exist? Do you have a mission statement that mentions inclusivity or access for all? Explain the implications of not addressing your website’s accessibility and how it affects so many of your users.

If you want to learn more about website accessibility have a look at the edX course Introduction to Web Accessibility. This is a free short course which explores the topics in this resource further.