Skip to main content
Socitm better connected logo

Access for people with disabilities

Why important

Websites must be as accessible as possible for all users, including people with disabilities, who account for around 15% of the UK population. Badly designed and implemented websites can make it difficult or impossible for people using assistive technologies like text-to-speech screen readers or magnification software. Legal requirements, pressure from government policy and simple good practice encourage the commissioning and supply of accessible websites. Accessibility should be 'built in' rather than be regarded as an extra layer of usability for a minority of users, not least because there is plenty of evidence that shows accessible websites are easier for everyone to use. Sites should be built to the WCAG 2.0 global web standard. It is important for web managers to understand that accessibility cannot be guaranteed by coders: where content management systems are used accessibility problems can be introduced where editors carelessly add links like ‘click here’, or forget to add ‘Alt text’ to an image.

Date of assessment

November/December 2015


All UK councils


Better connected accessibility testing is undertaken by the Digital Accessibility Centre (DAC). For each type of council, testers (all of whom have disabilities and may be using assistive technologies) attempted to complete three specified tasks from the 2015-16 survey set, one of them from a mobile device. Testers simply try to complete the task (eg ‘report missed bin’) rather than complete the survey questions used by our main review team. There is a fourth test covering the site’s top pages (home, contact us, and one covering council services; business services; and resident services). Each test covers 14 aspects of accessibility, with scores aggregated to give each task a rating on a scale of 0-3 and further aggregated to give an overall site score. Those achieving 2 or 3 overall are deemed to have passed the accessibility test. In 2016 64% of councils passed, compared with 43% in 2015 and 26% in 2014. This trend to improvement is associated with the simpler, less cluttered websites being designed for access from mobiles.

Find your council report

Go to councils page and select your council. Look for link to task report under 2015-2016 results

Headline Results


Provide a good or very good online service based on this survey (43% in 2015)

Performance by council type

KEY CC = County Council, SD = Shire district, LB = London borough, MD = Metropolitan district, EU = English unitary, WU = Welsh unitary, SU = Scottish unitary, NI = Northern Ireland district

Pass 2016 (%) 56 64 45 70 58 63 81 68 64
Pass 2015 (%) 52 46 n/a 45 47 36 72 41 43

Task report

As well as describing the ‘all council’ results for usability testing in 2015-16, this report describes the method of testing, the criteria used, and the scoring.

This is designed to help non-experts understand what action is needed to take to make their sites accessible, based on their individual accessibility report. Clearly, our test only covers a sample of pages from each website so subsequent action needs to ensure that sites are accessible throughout.

Every member of the DAC user testing team has a disability, among them visual impairment, dyslexia, mobility impairment and learning disabilities. Most testers will be using one or more assistive technologies to access sites from their computer or mobile device including screen reader software, voice activation software, screen magnification software, and keyboard only reliance. Deaf users and those with dyslexia or low vision will do manual checks.

Three tasks from the main survey are tested for each council, one of them a mobile task. The fourth ‘task’ tested covers the site’s top pages (home, contact us, and one top page covering council services; business services; and resident services).

DAC use 14 criteria to measure the accessibility of each task. These are described below. Each criterion highlights issues that cause problems and assigns points based on severity. Weighting is added to reflect the frequency of occurrence within tasks tested. Scores for each task are arrived at by combining the results for the 14 criteria in to a single score. Scores for each site are based on aggregating the task scores.

Where a task is so inaccessible that DAC testers cannot start or complete it, the task is given a score of 0. These ‘show stoppers’ (indicated as such by the international accessibility standard WCAG 2.0) are:

  • Keyboard traps
  • Auto-starting audio
  • Flashing content
  • CAPTCHA without an accessible alternative


Further information about these is given within the criterion descriptions below.

Where DAC find serious issues that would challenge specific user groups, the task was given a 1. These tasks could usually be completed and individual reports provide scores and comments where these ‘difficult’ issues occur. Sites that are not responsive when presented the users’ mobile device result in a difficult user experience and are also given a score of 1.

Where tasks cannot be completed because, for example, the website required users to add an address or other details in order to continue, they are ignored when calculating the final scores.

All other tasks are are given scores for each criterion which are then aggregated to arrive at  a task score.

Common reasons for poor performance in the 2015-16 accessibility tests

Issues encountered on third party sites played a big part in the overall ratings in this year’s results. In general, the most common issues on desktop tasks were found for the following criteria:

2. Heading structure
3. Present and functioning visible skip links
6. Clear labels and instructions for forms
11. Avoidance of movement on pages

Pay council tax

There were a significant number of councils using a third party website to enable completion of this task. This meant that although the majority of council pages scored really well, the accessibility of third party websites let them down. Some online forms were problematic where mark up of the form fields were non-descriptive, and mandatory fields were problematic for screen reader users since screen reader users will not know whether the field requires an entry and therefore will continue with the completion of the form not knowing that any errors have been made. Also, a large number of sites failed on ‘visible link focus on tab’ (criterion 5) and ‘skip links’ (criterion 3) that meant users were unable to bypass the navigation to the main content.

When commissioning software, councils need to reassure themselves that it can meet accessibility standards and whether this is part of the standard features of the product.

Renew a library book

Approximately half of the councils used a third party website for this task. As with the previous task, this meant that although the majority of council pages scored really well, the accessibility of third party websites often let them down. Some online forms were problematic where mark up of fields was non-descriptive. Mandatory fields were also problematic for screen reader users.  Again, screen reader users will not know whether the field requires an entry and therefore will continue with the completion of the form not knowing that any errors have been made. If form fields are not marked up correctly, screen reader users will not understand the content and become stuck in areas.

Find out about how to apply for housing

There were very few issues encountered when finding information on ‘how to apply for housing’, main because this was an information only task where there were no forms to complete.

Register a food business

It was very often the case that either the information could not be found or was difficult to find. The only councils tested on this task were Northern Ireland districts, and this is a content rather than an accessibility issue.

Find out about my councilor

There were very few issues encountered when finding information on ‘find out about my councillor’.

Mobile tasks

The main issue in both of the mobile tasks (‘find opening times for council tip’ and ‘report missed bin’) was lack of sequential navigation (criterion 4).  When attempting to complete forms, radio buttons and checkboxes were often by-passed. Many websites were encountered that had not been purposed for mobile although this was fewer than last year (other Better Connected testing shows a rise in sites purposed for mobile devices up from 57% in December 2014 to 80% in March 2016).  Illogical heading structures (criterion 2) were also apparent.

Another common issue was ‘bleedthrough’ - content being announced that is not present on screen. This comes under criterion 4, as the sequential navigation is not logical, leaving users with screen readers unaware of where they are on a page. Unclear labels for form fields and/or associated controls (criterion 6) cropped up frequently too.

DAC found a significant number of websites where ‘visible focus indicators on links and form elements’ (criterion 5) were absent. This seems to be a trend on websites designed to work more effectively above Internet Explorer 9. This caused a large number of sites to score no more than one on some or all tasks.


The 14 criteria used for testing and scoring tasks

DAC scores tasks and top pages against 14 criteria, marking issues on a scale of 0-10 where 0 is accessible and 10 is a ‘showstopper’ – ie some users will not be able to access content at all. Web managers can use the explanations below to understand results from the individual test report published on their own council’s pages this site.

1. Unique and informative page titles    

This issue impacts blind users who use screen reading software, since page titles provide a form of navigation for these users.

All online pages should have unique topics that describe the content of the page or document. This is the very first element that a screen reader user hears when navigating to a page, so it is very important that the page title be unique and front load the information. Page titles must appear to be in an appropriate format which conveys the specific content of the page, presenting the distinguishing information first: this is known as ‘Front-loading’ the page title. Developers should ensure that web pages include a TITLE tag within the HEAD area, and the title should be unique to each page on the Web site.


6 - Page titles missing or inaccurate
4 - Page titles not front loaded

Although missing titles would fail the WCAG 2.0 criteria, this would not be deemed ‘difficult’ in terms of completing a journey. 

2. Good heading structure                        

This impacts blind users who use screen reading software.

Another way for people using this technology can get an overall impression of a page's content is to jump from heading to heading. Users can hear an outline of the page's main areas similar to a user reading a newspaper, scanning the headings that take a user’s interest the most. The main drawback to this technique is that too many pages lack headings, or are presented in an illogical hierarchy, confusing screen reader users about the actual structure of pages. Headings should represent an accurate outline of the content.


8 – No Headings on the page
6 – Empty Heading mark-up
3 – Heading structure is not a logical hierarchy
2 – Heading mark-up is clearly used only for visual formatting of text
0 – Accessible

A well-structured hierarchy will help convey the appropriate information and related information to a screen reader user. It is important to note that a logical hierarchy does not jump a level when descending through the structure, but can when ascending depending on the layout of the webpage. This would be deemed ‘difficult’ in terms of completing a journey. 

3. Present and functioning visible skip links                

This impacts blind users who use screen reading software and mobility impaired users who rely on keyboard navigation

Skip links at the top of the page, which allow users to skip over the navigation links, are a method of getting straight to the main content of the page. Such links speed up the reading process and help users distinguish between the main navigation and the main content. Where appropriate, users should be allowed to skip over repetitive navigation links, especially if there are many navigation links.


8 – No skip link present or functioning
0 – Skip link must be present and either permanently visible or becomes visible on focus for keyboard use

There must be available feature provided for a keyboard only user to bypass menus/navigation. Ideally this would be permanently visible; however, this can be made to appear when tabbed to.
Although no skip links present would fail the WCAG 2.0 criteria, this would not be deemed ‘difficult’ in terms of completing a journey. It adds to a keyboard only users’ navigation as they have to tab through menus/navigation.   

Limit scrolling to one direction (mobile use)

The page should lay out so that simple repeated scrolling in the same direction (axis) allows the user to experience all its content. However some content (such as maps and other images) cannot be displayed without secondary scrolling.


8 – Swipe gesture was required for navigation to off-screen content
0 – Swipe gesture was not required for navigation to off-screen content or an alternative was in place

Sequential navigation is a main form of navigating for VoiceOver/TalkBack users, it means that they can swipe through the page in a logical order. If the sequential navigation is not logical it would be deemed ‘difficult’ in terms of completing a journey.

4. All-important content reachable by keyboard navigation    

This impacts mobility impaired users and blind users using keyboard controls or technologies that mimic the keyboard rather than a mouse.

Some people cannot use a mouse, including many older users with limited fine motor control. An accessible website does not rely on the mouse: it provides all functionality via a keyboard. Then people with disabilities can also use assistive technologies that mimic the keyboard, such as speech input. This can be via voice activated technology, such as Dragon Naturally speaking. Elements should be designed on a page so that they are navigated to in a logical manner the way your eyes would scan a page, i.e. from top to bottom, left to right. Keyboard users should not be trapped in a section, and should be allowed to pass through and navigate freely back and forth.


10 – A keyboard trap is present (showstopper)
5 – The tab order is not logical or consistent
0 – Accessible

All important content reachable in sequence (mobile use)

This impacts blind users who use screen reading software. Screen reader users navigating via a touchscreen device need to reach all areas in a logical order. Developers need to be aware of certain elements/functionality that causes a user to become trapped in an area, preventing the user from further task completion.


10 – A trap is present (showstopper)
5 – The page’s sequential order is not logical or consistent
0 – Accessible

A logical tabbing order is vital on pages to enable keyboard only users to navigate a page/s, meaning they can tab through the page in a logical order without becoming lost.
If the sequential navigation or tabbing order is not logical it would be deemed ‘difficult’ in terms of completing a journey.

5. Visible focus indicators on links and form elements    

This impacts low vision, colour blind and dyslexic users.

Visible focus helps all users by providing a way to navigate, find content, and determine where they are on a page or application. Mouse users as well as keyboard users rely on a good visible differentiation when focus is placed on an element. Ideally the difference between the focus state and the normal state should be a difference of 4.5:1 in colour difference and/or provide an alternative visual cue, such as bold or underline.


8 – Page elements do not change to show they are in focus
4 – Link text does not have an additional cue, when in focus, to indicate that a link is present
0 – Accessible

If a keyboard only user comes across an element that has no visible link focus on tab, the user can lose track of the current focus and become disorientated.This would be deemed ‘difficult’ in terms of completing a journey.

Website delivers a mobile dedicated design (mobile use)

This impacts all users

It creates problems for all users if page elements do not change to deliver a mobile specific (responsive) experience. Navigation becomes more difficult and content may not wrap to the size of the screen on the specific device. Problems are slightly less severe if there is a link provided somewhere on the page to a mobile version of the website. Ideally, an automatic mobile dedicated design should be delivered.

8 – Page elements do not change to deliver a mobile specific experience
4 – An automatic mobile experience is not delivered. A link option has been provided on the page
0 – Accessible

If a mobile specific (responsive) theme is not present it would be deemed ‘difficult’ in terms of completing a journey.

6. Clear labels and instructions for forms                

This impacts blind users who use screen reading software

Visible labels on forms that are easy to identify benefit all web users who are able to see them. Screen reader users also need to be able to identify and use form inputs. Most modern screen readers will automatically switch to ‘forms’ mode when focus is shifted to a form element, and back to ‘virtual cursor’ mode when focus shift to non-form elements. It is important that descriptive labels or instructions are provided when content requires user input.


7 – Form field and/or buttons are not labelled descriptively; labels are not associated with corresponding fields using For & ID; groups of associated fields are not using fieldset & legend
3 – Error handling using Mandatory fields & error reporting techniques not implemented
0 – Accessible

Insufficient information is one of the main obstacles currently encountered by some groups of disabled users. Unlabelled form fields convey no meaning to a screen reader users, preventing them from being able to enter the appropriate information and complete the desired task. If form field elements are not labelled appropriately it would be deemed ‘difficult’ in terms of completing a journey.

7. Meaningful links in context                

This impacts blind users who use screen reading software.

Links should make sense when read out of context. Also, the distinguishing information of the link should be at the beginning of the link. This will help blind users when navigating a web or mobile site. Stay away from using link text such as ‘Click here’ or ‘more’ as this gives no meaning to where the link will take the user.


6 – Link text is not descriptive enough in context
3 – Link descriptions are not uniquely descriptive out of context (i.e. Click Here)
0 – Accessible

Links descriptions should not contain URLs as these can provide no indication as to the link's purpose. Also, links read out of context i.e. ‘Click here’ in these situations the additional text can be hidden off the visual screen using CSS SPAN and then a more descriptive label can be read back to screen reader users. If links were found to lack the necessary descriptions to convey their purpose/function to a screen reader user it would be deemed ‘difficult’ in terms of completing a journey.

8.Appropriate text alternatives for images                

This impacts blind users who use screen reading software and low vision users.

ALT text is the alternative text for images that gets read out to screen reader users. Any website offering even basic accessibility will provide this alternative text. Some websites try to over-explain the information conveyed by images, forcing screen reader users to have to listen to a lot of unnecessary and irrelevant information. Provide succinct ALT text for images that help convey meaning to the user. Editors should provide alt text on image links that describe the destination page and a null alt=”” text attribute on images that are required to be ignored by screen readers.


10 – use of Captcha without an accessible alternative
6 – No alternative description is present for an image which does not have a null alt
3 – An alternative description is not descriptive enough
1 – An image description duplicates its neighbouring text link
0 - Accessible

Inaccessible CAPTCHA - ie it is not read back to screen reader users through Screen reading software - means an instant fail. When images are not given alternative text descriptions, in most cases, screen reading software will try to read what it can to the user, this usually takes the form of a file path which will make no sense to screen reader users. <alt=“”>If images have no alt attributes or non-descriptive alt attributes it would be deemed ‘difficult’ in terms of completing a journey.</alt=“”>

9. Sufficient colour contrast    

This impacts colour blind and dyslexic users.

Colour contrast is important for colour blind and dyslexic users because they cannot perceive (see) the difference between certain color combinations. The colors with which they have difficulty distinguishing depend upon their type of color-blindness, but red-green deficiencies are the most common. Developers and editors should be aware that the colour contrast ratio of text against background should be at least 4.5:1


6 – Important information is not conveyed relying on the use of colour alone.
4 – Links, areas of text and/or Images do not satisfy a colour contrast ratio of 4.5:1
0 – Accessible

Because people perceive colour and contrast to different degrees DAC uses the W3C recommendations as a benchmark. The Colour Contrast Analyser tool is a useful benchmark for colour contrast and we find that compliance with this tool is acceptable. Developers must take care to ensure that colour contrast meets the minimum requirements. If the standard scheme does not meet the minimum requirements, then an alternative colour scheme that does meet the requirements should be made available. The amount of content that cannot be read would determine the rating in terms of completing a journey.

10. Ability to resize text to 200% without loss of content                

This impacts low vision, dyslexic, and elderly users.

Users with low vision or who are elderly may require text to be enlarged in order to view content easily. Developers should ensure that content can be resized up to 200% without loss of content or obscuring information when users either zoom into content via ctrl and + or by using the browser text re-sizing facility to enlarge text itself.


4 – Resizing up to 200% causes visual loss of content through overlapping, obscuring or truncating
0 – Accessible

Many users choose to increase the size of text on their web page for various reasons. They must be able to increase the text size up to 200% by using browser control, zoom or text resizing widgets. Inability to do so would fail the WCAG 2.0 criteria but would not be deemed ‘difficult’ in terms of completing a journey.

11. Avoidance of movement on pages                

This impacts cognitive impaired, dyslexic and low vision users, as well as blind users who use screen reading software.

Movement on a page can be very distracting for users with cognitive or learning difficulties, especially if the user has no warning that is going to happen. The only place there should be movement is on the area the user is interacting with at that moment, for example when the user has chosen to play a video. If there is movement of any kind on the page that lasts for more than 5 seconds then a user (keyboard and mouse users) should be able to pause that movement.


8 – No accessible controls present to stop movement
0 – Accessible

Pages which contain moving content, especially perpetually moving content, must either appear in a paused state or have a pause control that can be utilised by all input devices due to the distraction this can cause. Although lack of controls to stop movement would fail the WCAG 2.0 criteria, it would not be deemed ‘difficult’ in terms of completing a journey.

12. No auto-starting for audio or video with sound                

This impacts blind users who use screen reading software.

Auto playing audio, and video with audio, is problematic for screen reader users as this may conflict with speech that is output from the screen reading software itself. This is particularly problematic if the user has not chosen to auto play the content, or if they are already listening to music, or another form of auditory material.


10 – Contents auto play after loading page [Show-stopper]
0 – Accessible

If any auto playing audio/video with audio was found during the testing this would automatically be deemed ‘Inaccessible’.

13. No flashing content        

This impacts epileptic, low vision, cognitive impaired, and dyslexic users.

Flashing content is problematic for many user groups, but more so for users with photo sensitive epilepsy as this may trigger seizures. If content flashes for 3 times in any one second then this is more likely to cause a seizure.


10 – Content flashes at a rate of 5 times per second or more [Show Stopper]
0 – Accessible

Flashing content automatically leads to a rating of ‘inaccessible’.

14. Accessible downloadable ‘non-html’ documents

This impacts all users.

Non html documents, like a PDF or a Word document should be made accessible to all user groups similarly to a web page. Non html documents may contain images, links and input fields. All of which require similar ways of dealing with such content when it comes to screen reader and other users. Disabled users frequently find that they are not able to access non-HTML documents. There are a number of actions that can be performed to reduce the impact of such documents:

•    Identify when it is appropriate to produce a non-HTML document
•    Consider using HTML pages as an alternative
•    Create a policy to help ensure that non-HTML documents are accessible
•    On any page where such a document is available, include a link to the appropriate reader plug-in page


8 – Inaccessible content (Forms)
3 – Inaccessible content (Images and headings)
0 – Accessible or not in use

All forms need to be accessible to keyboard control and entry.  Form fields should allow the user to digitally complete and fax them from the computer screen, not require a printed copy for another person to physically write and send if the user is unable to do so. PDF content, such as links, should be accessible, and forms should contain fields that can be tabbed to and edited as required. If PDF documents cannot be controlled it would be deemed ‘difficult’ in terms of completing a journey.




Post a comment (Login required)