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.
All UK councils
In collaboration with our testing partner Digital Accessibility Centre, Better Connected has developed a new, two-stage process for testing and reporting the accessibility of council websites. Stage one testing is designed to identify sites that would fail our fuller test and was run by DAC on all 416 UK council websites in December 2016. 275 of the UK’s 416 council websites (two thirds of the total) passed this test. Sites owned by Socitm Insight member/user councils that passed stage one, and others that failed, but applied for and passed a retest, were tested at stage two. Of the 195 sites tested at stage two, 69% passed. 77% of the same cohort of councils passed the test last year. These results should not be read as a deterioration, however, because different, and arguably more difficult tasks were tested this year. In particular, to pass ‘order a bulky waste collection’ which was a test conducted on a mobile device, sites had to offer an online order form (not a pdf) and further, that order form and its associated payment module (as well as the site overall) had to be responsive. Only 25% of all sites tested in our main BC survey on ‘order bulky waste collection’ had responsive forms, so it is not surprising to see that only 26% of sites tested at stage two passed this task. Analysis of results of the more directly comparable top pages task shows that 88% of our stage two cohort passed this task, compared with 82% in 2016.
Check ‘coverage’ to see if your council has been surveyed. Go to councils page and select your council. Look for link to task report under 2016-17 results
Provide a good or very good online service based on this survey
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 2017 (%)||71||89||100||81||76||62||72||38||69|
|Pass 2016 (%)||56||64||45||70||58||63||81||68||64|
NB pass rate in 2016 applies to all 416 councils. Pass rate in 2017 applies only to sample of 195 councils tested at stage two. This factor explains much of the improvement
How Better Connected tests accessibility
Councils should read this information in conjunction with their own individual accessibility report accessible from links on their headline results page (Councils tested at stage two: Socitm Insight members and users only).
Testing is carried out for Better Connected by the Digital Accessibility Centre. Each member of the DAC testing team has a disability, among them visual impairment, dyslexia, mobility impairment and learning disabilities. Most testers use 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 do manual checks.
In 2016-17 we introduced a new, two-stage process for testing and reporting the accessibility of council websites.
Stage one is a limited test designed to identify sites that would fail our fuller test. It examines home pages for the 14 testing criteria used in our full test. Sites fail stage one if they fail on 7 or more of the 14 criteria. They also fail if they fail on keyboard traps (criterion 4) or on lack of visible focus indicators (criterion 5) - issues that will make pages inaccessible to certain groups.
Sites failing stage one have the opportunity to fix the issue(s) identified and apply for a re-test ahead of stage two testing. Sites that fail the re-test or do not apply for one, are not tested at stage two. Detailed results of stage two tests are published for each council tested. Only councils that pass stage one and two of the accessibility test can achieve four stars in Better Connected.
Stage two testing applies the 14 testing criteria to three ‘top tasks’ per council, including one from a mobile device, as well as a range of top level pages (home, contact us, and one top page covering council services; business services; and resident services).
Each criterion is assigned points and weight based on a severity and/or frequency. The final score for each task is given by combining the results for the 14 criteria.
In some cases, it is clear from the beginning of the assessment that a task is completely inaccessible or at least very difficult for people with some disabilities.
In these cases, tasks are scored of 0.
In line with WCAG 2.0, four issues are deemed to be complete show stoppers and where they occur the task is also scored at 0:
Where serious issues were found that could be considered challenging for a specific user group, such as lack of link highlighting for keyboard users, the task was given a 1.
A rating of 1 was also given for tasks being assessed on mobile devices where the site was not responsive or otherwise purposed for mobile access, resulting in a difficult user experience.
Where a task couldn't be completed due to lack of information, for example, the website required users to add an address or other details in order to continue, the task was ignored when calculating the final scores.
For tasks that did not fall into any of the three groups above, we gave scores to each criterion and then calculated the final score for the task between 0 and 3.
Task report stage one
Designed to identify sites that would fail our fuller assessment, this test was run by DAC on all 416 UK council websites in December 2016.
275 council websites (two thirds of the total) passed this test. 23 councils applied for stage one retests and a total of 195 councils (Socitm Insight members or user councils successful at stage one) were tested at stage two.
Stage one headline results appear on all councils’ headline results pages and Socitm Insight members and user councils’ can view issues identified, including reasons for failure where relevant, linked from that page.
Task report stage two
For the reasons outlined above, fewer sites were subject to the full accessibility test in 2016-17.
195 sites that passed stage one were tested. Of these, 69% passed the test. This compares with a 77% pass rate by the same cohort of councils in last year’s test.
These results should not be read as a deterioration because different, and arguably more difficult, tasks were tested this year. In particular, to pass ‘order a bulky waste collection’ - a test conducted on a mobile device - sites had to offer an online order form (not a pdf) and further, that order form and its associated payment module (as well as the site overall) had to be responsive.
Only 25% of all sites tested in our main BC survey on ‘order bulky waste collection’ had responsive forms, so it is not surprising to see that only 26% of the cohort of sites tested at stage two passed this task.
Results of the more directly comparable top pages task shows that 88% of our stage two cohort passed this task, compared with 82% of the same cohort in 2016. The cohort tested in 2017 performed better than all the all council cohort tested in 2016 (77% vs 64%).
The most common reasons for failure of tasks tested on the desktop were:
Unclear labels for form fields and/or associated controls (criterion 6)
No visible working skip links (criterion 3) – these were either not visible when tabbed to, or did not having the correct markup in order to skip a user to the main content within the page.
Illogical heading structure (criterion 2) – for those using screen reading software, jumping from heading to heading enables them to get an overall impression of a page’s content. This is problematic if headings have not been created with this in mind.
Moving content without a means to pause or stop (criterion 12)
No visible link focus on tab (criterion 5) - This was an issue with desktop and mobile versions of sites. When keyboard-only users tab through a page they often become lost, making tasks difficult to complete. The issue seems to appear on websites designed to work more effectively in Internet Explorer 9 and above. It caused several sites to score no more than one on some or all tasks.
The most common reasons for failure of tasks tested on mobiles were:
No online form available – this means some users with disabilities cannot complete the task because they cannot use the phone or email.
Sometimes forms were available but were themselves not responsive, or there was a non-responsive payment module.
Where forms a presented as non-HTML documents, users with disabilities often that they are not able to access them. Councils should try to: use HTML pages as an alternative; if they are used, ensure that non-HTML documents are accessible; on any page where such a non-HTML page is used, include a link to the appropriate reader plug-in page
The site was not responsive or otherwise purposed for mobile access. When sites are purposed for mobile, there is usually more limited content, which is then easier to find on a small screen. The content will also be larger so that users with low vision do not have to magnify as much of the screen as would be necessary if they had a full desktop screen presented to them in a limited space.
‘Bleedthrough’ - where content not present on the screen was picked up and read out by screenreaders, this prevents content being reached in sequence, confusing the user’s progress through the task
Advertisments and editorial that include moving content that moves for more than 5 seconds (eg ‘slider’ features) should either appear in a paused state or have a pause control that can be utilised by all input devices (including keyboards) due to the distraction this can cause. See criterion 11 for more details.
Adverts sometimes contain ‘iframed’ content that causes a keyboard trap. This is solved by developers removing the frame from the keyboard tab order of the page.
Where websites use maps to enable visitors report issues (as in our pavement defect task), a form should be provided as an alternative to make reporting accessible to those unable to place an icon onto a specific location on a map.
More generally, websites need to offer forms for reporting, applying, booking, and contacting the council, since some users with disabilities will be unable to communicate by phone or use email because of its unstructured format. Forms themselves must be responsive so that they are usable from mobile devices.
Mandatory fields were problematic if notified to users via an asterisk or notified in text. Notification also needs to be within the
Visible labels 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.
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.