Accessibility statement for norfolk.gov.uk

Introduction

This accessibility statement applies to www.norfolk.gov.uk. It doesn't cover subdomains such as communitydirectory.norfolk.gov.uk, which are covered by other accessibility statements.

This website is run by Norfolk County Council.

We want as many people as possible to be able to use this website.

For example, that means you should be able to:

change colours, contrast levels and fonts
zoom in up to 400% without the text spilling off the screen and without content being truncated or overlapping
navigate most of the website using just a keyboard
navigate most of the website using speech recognition software
listen to most of the website using a screen reader (including the most recent versions of JAWS, NVDA and VoiceOver)

AbilityNet has advice on making your device easier to use if you have a disability.

How accessible this website is

We aim to meet the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG) 2.2 at AA level.

However, we know some parts of this website are not fully accessible.

Issues potentially affecting everyone

Pages reload unexpectedly when files are uploaded on some pages in the admissions application process.
Some form controls do not have visible labels in the general enquiry form, highways problem report form and admission application process. In the general enquiry form, some labels incorrectly state that the corresponding textbox is optional when it is mandatory.
The email form field in some email newsletter sign up forms does not support autocomplete.
On some forms, the visual positioning of error messages may make it unclear to some users which field the error message applies to.
Interacting with the captcha challenge on some webforms may trigger a change of context users do not expect.
The captcha challenge on some webforms has a time limit that users can't turn off, adjust or extend.
The captcha challenge on some webforms may be difficult to use when CSS is disabled.
Some videos have incorrect captions.

Issues affecting people with low vision

Throughout the website there are a small number of combinations of text and background colour that do not have sufficient colour contrast. Most are specific to individual pages.
Some textbox borders have low colour contrast against the background colour, so they may not be easy to see. The focus indicators for some textboxes and radio buttons have low colour contrast against the background, so they also may not be easy to see.
The slider switches in the admission application process have low colour contrast against the background so they may be difficult to see. Their focus indicators also have very low colour contrast.
Some buttons, checkboxes and comboboxes have the browser's default focus indicator. This has good colour contrast against the background in most browsers, but it has very low colour contrast in Safari so it may not be easy to see. Some checkboxes also have the browser's default styling. The checkbox borders have good colour contrast against the background in most browsers, but they have very low colour contrast in Safari so it may not be possible to see them.
We link to Power BI data dashboards from three pages on the website. If users adjust text spacing, browser zoom and/or display resolution, some content is not visible, or is only visible when scrolling in two dimensions.
The captcha challenge on some webforms sometimes requires users to scroll in two dimensions when zoomed in.
Some links only use colour to distinguish them from standard text
When resizing the text on some pages, some content becomes obscured

Issues affecting people who use keyboard navigation

The focus indication for many links, buttons and form controls is conveyed only by a small change of colour, so it may be difficult to tell which component has focus.
Some buttons cannot be operated using keyboard controls, either because they do not receive focus, or they receive focus but do not respond to the Enter key being pressed.
We link to Power BI data dashboards from three pages on the website. Users can't navigate to all interactive interface components using a keyboard and focus is not always visible.
Some email newsletter sign up forms do not show error messages when the form hasn't been correctly completed and the user attempts to submit the form using a keyboard. This makes it hard for users to identify errors they have made and correct them.
It's not always possible for users to tab to all buttons within the captcha challenge on some webforms.
When interacting with the captcha challenge on some webforms, it's not always visually obvious which component has focus.
There are some tab orders that are not logical.
StoryMaps content we link to has autoplay controls that are not always accessible using a keyboard

Issues affecting screen reader users

Some images in the general enquiry form do not have text alternatives.
Some embedded YouTube videos do not have audio description.
In the YouTube videos, the timeline slider does not convey the current time to screen readers, so it is difficult to set the slider to a specific time.
Some forms have unlabelled or incorrectly labelled fields
In some forms, error messages are not announced automatically when the form is submitted, so it is necessary to explore the page to find the errors.
Some forms contain textareas that have character counters. The number of remaining characters is not announced automatically, so it is necessary to leave the textarea in order to read the character counter.
Many Word documents and older PDF documents are not fully accessible to screen reader software.
Some financial information is published in csv files, which do not include table formatting that accurately conveys visual information to screen reader users.
Some information about major highways projects is published using templates required by the Department for Transport. Some parts of these documents do not accurately convey visual information to screen reader users.
Some statement of accounts documents include table formatting that inaccurately conveys information shown visually.
Some email newsletter sign up forms tell screen reader users that all fields have invalid input until they have been completed correctly. This may confuse users as this is not typical form behaviour.
On some forms, when an error message appears to indicate that the user has not provided their address correctly using the address look up tool provided, visual styling communicates all the fields the error message relates to, but this information is not conveyed programmatically.
The link text for some links doesn't sufficiently describe the purpose of the link. This may make it difficult for users to understand what they relate to. This includes links within the captcha challenge on some webforms.
The captcha challenge on some webforms has error messages that aren't sufficiently associated with the relevant content or determinable without receiving focus. The checkbox functions as a required field but this is not conveyed programmatically.
Some images do not have descriptive alternative text.
Some tables have not been coded correctly.
Some iframes do not have title.
On the 'Types of waste we accept' page, when typing in the 'Quick search items' field, there is no indication to a screen reader user that the content on the page has changed.
Some pages have multiple languages present that are not correctly coded
StoryMaps content we link to has some components in the page header that are not coded correctly and have insufficiently descriptive labels

Feedback and contact information

If you need information on this website in a different format like accessible PDF, large print, easy read, audio recording or Braille, email webaccessibility@norfolk.gov.uk

We're always looking to improve the accessibility of this website. If you find any problems not listed on this page or think we're not meeting accessibility requirements, email webaccessibility@norfolk.gov.uk

We'll consider your request and get back to you in 3 working days.

Enforcement procedure

The Equality and Human Rights Commission (EHRC) is responsible for enforcing the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (the 'accessibility regulations'). If you're not happy with how we respond to your complaint, contact the Equality Advisory and Support Service (EASS).

Contacting us by phone or visiting us in person

We provide a text relay service for people who are D/deaf, hearing impaired or have a speech impediment.

Our offices have audio induction loops, or if you contact us before your visit, we can arrange a British Sign Language (BSL) interpreter.

Technical information about this website's accessibility

Norfolk County Council is committed to making its website accessible, in accordance with the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.

Compliance status

This website is partially compliant with the Web Content Accessibility Guidelines (WCAG) version 2.2 AA standard, due to the non-compliances and exemptions listed below.

Non-accessible content

The content listed below is non-accessible for the following reasons:

Non-compliance with the accessibility regulations

WCAG level A

Some images do not have text alternatives. This fails WCAG 1.1.1 Non-text Content
Some embedded YouTube videos do not have accurate captions. This fails WCAG 1.2.2 Captions Prerecorded
Some embedded YouTube videos have visual content that is not conveyed in the audio track, but audio described versions of the videos have not been provided. This fails WCAG 1.2.3 Audio Description or Media Alternative (Pre-recorded)
Some visual headings are not marked-up as headings, and some are marked-up as the wrong heading level. This fails WCAG 1.3.1 Info and Relationships
Some buttons have labels that don't include information provided by visual presentation. This fails WCAG 1.3.1 Info and Relationships. This includes:
- The 'Show more'/'Close' button in the cookie control
- The 'More' button in secondary navigation menus
- Pages where there is more than one button with the label 'Search'
- Embedded YouTube and Google Maps content
The HTML markup of some tables doesn't include some information provided by visual presentation. This fails WCAG 1.3.1 Info and Relationships
Some iframe elements do not have a title that accurately describes their visible content. This includes the map on the Getting to County Hall page and email newsletter sign up forms across the site. This fails WCAG 1.3.1 Info and Relationships
Several Word documents require user input (act as editable forms or templates) but have visible labels or instructions that aren't programmatically associated with the form field. This fails WCAG 1.3.1 Info and Relationships
Some financial information is published in csv files, which do not include table formatting that accurately conveys information shown visually. this fails WCAG 1.3.1 Info and Relationships
Some information about major highways projects is published using templates required by the Department for Transport. Some parts of these documents do not accurately convey information shown visually. This fails WCAG 1.3.1 Info and Relationships
When the page is linearized, the captcha challenge dialog present on some webforms is positioned after all the other page content (ie. after the footer). This affects its meaning - it's no longer visually associated with the captcha checkbox. This fails WCAG 1.3.2 Meaningful Sequence
The focus indication for many links, buttons and form controls is conveyed only by a change of colour. This fails WCAG 1.4.1 Use of Colour
Links within paragraphs of text only use colour to distinguish them from standard text. This fails WCAG 1.4.1 Use of Colour
Some buttons do not receive focus, so they cannot be operated using keyboard controls. Some other buttons receive focus but still cannot be operated using keyboard controls. This fails WCAG 2.1.1 Keyboard
We link to Power BI data dashboards from three pages on the website. Users can't navigate to all interactive interface components using a keyboard. This fails WCAG 2.1.1 Keyboard
When interacting with the captcha challenge on some webforms, once a user has navigated to the new challenge, audio/visual challenge and help buttons once, they cannot navigate back to them using a keyboard. This fails WCAG 2.1.1 Keyboard
StoryMaps content we link to has an autoplay function. The autoplay controls are only possible to navigate to using a keyboard when they are visible. Sometimes it is not possible for the user to make them appear without using a mouse. This fails WCAG 2.1.1 Keyboard
The captcha challenge on some forms expires and errors after two minutes. The user must tick the checkbox and complete a new challenge. They are not given the option to turn off, adjust or extend the time limit. This fails WCAG 2.2.1 Timing Adjustable
Carousels across the site have an illogical focus order. This fails WCAG 2.4.3 Focus Order
Within the captcha challenge on some webforms, the 'Privacy', 'Terms' and 'Learn more' link text does not sufficiently describe the purpose of the links. This fails WCAG 2.4.4 Link Purpose (In Context)
The 'Education and Learning' link on some SEND local offer pages and links relating to personal assistant job vacancies have link text that does not sufficiently describe the purpose of the links. This fails WCAG 2.4.4 Link Purpose (In Context)
Links in carousels across the site do not have any link text. This fails WCAG 2.4.4 Link Purpose (In Context)
On the 'Types of waste we accept' page, when typing in the 'Quick search items' field, there is no indication to a screen reader user that the content on the page has changed. This fails WCAG 3.2.2 On Input
Pages reload unexpectedly when files are uploaded on some pages. This fails WCAG 3.2.2 On Input
When interacting with the captcha challenge on some webforms, checking the checkbox sometimes triggers a change of context (a dialog opens). The user is not warned this is going to happen. This fails WCAG 3.2.2 On Input
StoryMaps content we link to has an autoplay function. The autoplay controls are only possible to navigate to using a keyboard when they are visible. Sometimes it is not possible for the user to make them appear without using a mouse. This fails WCAG 2.1.1 Keyboard
On some forms, when error messages appear to indicate that the user has not completed the form correctly, the error messages are positioned above the field label. This may make it unclear to some users which field the error message applies to. This fails WCAG 3.3.1 Error Identification
On some forms, when an error message appears to indicate that the user has not provided their address correctly using the address look up tool provided, visual styling communicates that the error message relates to the 'Find address' and 'Address' fields, but this information is not conveyed programmatically. This fails WCAG 3.3.1 Error Identification
Some email newsletter sign up forms do not provide error messages when one or more fields do not have valid input and the user attempts to submit the form using a keyboard. This fails WCAG 3.3.1 Error Identification
Some email newsletter sign up forms include 'aria-invalid="true"' on all form inputs until they have valid input, which triggers the value to change to "false". This is incorrect use of the attribute - on form load it should be set to "false" and it should only be set to "true" if invalid input is detected when validation is performed. This fails WCAG 3.3.1 Error Identification
The captcha challenge on some webforms has error messages that aren't sufficiently associated with the relevant content. The checkbox functions as a required field but this is not conveyed programmatically. This fails WCAG 3.3.1 Error Identification
Buttons in image galleries and some form controls do not have labels. This fails WCAG 3.3.2 Labels or Instructions
StoryMaps content we link to has some components in the page header that do not have sufficiently descriptive accessible labels. For example, the 'Print preview' button in the 'More actions' menu includes visible text in a tooltip that appears on mouse hover 'Print or save as PDF'. This text is not accessible for assistive technologies. This fails WCAG 3.3.2 Labels or Instructions
In the YouTube videos, the timeline slider does not convey the current time programmatically. This fails WCAG 4.1.2 Name, Role, Value
Several Word documents require user input (act as editable forms or templates) but do not have programmatically determinable form fields. This fails WCAG 4.1.2 Name, Role, Value
Some form controls do not have accessible names in the general enquiry form, Norfolk Assistance Scheme form, highways problem report form and admission application process. Some buttons in the highways problem report form also do not have a role. Throughout the website, file upload buttons do not have an accessible name. This fails WCAG 4.1.2 Name, Role, Value
StoryMaps content we link to has some components in the page header that are not coded correctly. For example, the 'Share' and 'More actions' buttons in the page header are both nested in containers (div elements) with the attributes 'role="presentation"' and 'aria-expanded'. ARIA rules state that 'aria-expanded' can't be applied to an element with 'role="presentation"', because the semantics of any elements with 'role="presentation"' are automatically ignored by assistive technology. This means the user will not be told about the presence of the 'aria-expanded' attribute, so can't benefit from it. This fails WCAG 4.1.2 Name, Role, Value

WCAG level AA

Some embedded YouTube videos have visual content that is not conveyed in the audio track, but audio described versions of the videos have not been provided. This fails WCAG 1.2.5 Audio Description (Pre-recorded)
The email form field in some email newsletter sign up forms does not include the attribute and value 'autocomplete="email"'. This fails WCAG 1.3.5 Identify Input Purpose
Throughout the website there are a small number of combinations of text and background colour that do not have sufficient colour contrast. This fails WCAG 1.4.3 Colour Contrast
When resizing text, the 'Search' button in the website header is obscured. Some text on the 'Types of waste we accept' page is also obscured. On some pages, some text does not resize at all. This fails WCAG 1.4.4 Resize Text
At display resolution 1280 x 1024 and browser zoom 400%, users must scroll both horizontally and vertically to see all content in the captcha challenge on some webforms. This fails WCAG 1.4.10 Reflow
Some textbox borders do not have sufficient contrast against the background colour, so they may not be easy to see. The focus indicators for some textboxes and radio buttons do not have sufficient colour contrast against the background, so they also may not be easy to see. This fails WCAG 1.4.11 Non-text Contrast
The slider switches in the admission application process do not have sufficient colour contrast against the background so they may be difficult to see. Their focus indicators also have very low colour contrast. This fails WCAG 1.4.11 Non-text Contrast
We link to Power BI data dashboards from three pages on the website. If users adjust text spacing, some content is not visible. This fails WCAG 1.4.12 Text Spacing
When interacting with the captcha challenge on some webforms, some components do not have a visible focus indicator. This fails WCAG 2.4.7 Focus Visible
We link to Power BI data dashboards from three pages on the website. If users adjust browser zoom and/or display resolution, some content is not visible, or is only visible when scrolling in two dimensions. This fails WCAG 1.4.10 Reflow
We link to Power BI data dashboards from three pages on the website. Focus is not always visible. This fails WCAG 2.4.7 Focus Visible
Some pages have multiple languages present that are not correctly coded. This fails WCAG 3.1.2 Language of Parts
In some forms, the error messages are status messages, but they are not in ARIA live regions. This fails WCAG 4.1.3 Status Messages
Some textareas have character counters. These are status messages, but they are not in ARIA live regions. This fails WCAG 4.1.3 Status Messages
Error messages for the captcha challenge on some webforms are not programmatically determinable without receiving focus. This fails WCAG 4.1.3 Status Messages

Disproportionate burden

There are two parts of our statement of accounts documents that we're not able to make accessible:

Complex written content that's not in plain English
Complex tables that don't have an accessible layout

We're unable to rewrite or redesign this content to make it more accessible. This is because the current format is required by the Code of Practice issued by the Chartered Institute of Public Finance and Accountancy (CIPFA) and International Accounting Standards.

Publish an alternative, accessible version

We've investigated whether we can publish an accessible version of statement of accounts documents alongside the original, inaccessible version.

We've found this wouldn't be a feasible solution because:

Our finance team have a limited timescale to produce draft statement of accounts documents between 1 April and 31 May each year. This timescale is dictated by account auditing requirements. This is a very tight timescale given the nature and volume of the content, so our finance team only have capacity to produce the original document during this time. We estimate that producing an additional, accessible version of the draft statement of accounts would cost at least £21,000 and take 7 weeks to complete. This is a disproportionate cost in relation to overall budget. It would also result in the accessible version not being available until 7 weeks after the original document has been published, which isn't an effective accessible solution.
Once a draft statement of accounts document has been published, we must arrange for it to be reviewed by a third-party auditor. Then we must publish a final version of the statement of accounts document, issued by the auditor, which includes their commentary. As the accessible version doesn't meet Code of Practice requirements, it can't be audited and therefore a final version can't be published that includes the auditor's commentary. This means that the final original version would include information the final accessible version would not, which isn't an effective accessible solution.

Improve accessibility using HTML format

We currently publish statement of accounts documents in PDF format. We've investigated whether we can publish the documents in HTML format instead to enable us to use HTML to improve the accessibility of the tables for assistive technology users without changing their visual appearance. This would not make the documents fully compliant with accessibility standards, but it would improve them.
We've found this wouldn't be a feasible solution because:
Our finance team would need to produce the draft statement of accounts document in Word document format initially. Then, once this has been completed, supply it to our website team to publish it as an HTML document. This effectively requires the creation of two documents, so would result in a similar additional cost (at least £21,000) and publication delay (7 weeks) as the option to produce both an original version and an accessible version. This means we wouldn't be able to publish the HTML document by the 31 May deadline.
Our auditor has advised that publishing draft statement of accounts documents in HTML format will make them more challenging to audit, resulting in additional work and cost, and impaired audit assurance. They suggest that the additional cost is likely to be a substantial additional to the total audit cost. For reference, the total audit cost for 2023-24 was approximately £357,000. A conservative estimate is that the additional cost would be at least a 10% addition to previous total costs (£35,700). This is a disproportionate cost in relation to overall budget.

Conclusion

We've concluded that it isn't possible to publish accessibility compliant statement of accounts documents without failing to meet CIPFA Code of Practice standards and timescales, or incurring excessive costs. This would place disproportionate burden on Norfolk County Council.

We will therefore continue to ensure new statement of accounts documents we publish meet accessibility requirements, except for the wording and tables.

We hope that the CIPFA will update their Code of Practice to acknowledge digital accessibility requirements and enable us to comply with both this standard and accessibility requirements.

This disproportionate burden assessment was made in May 2024. We will review it again in May 2025.

Content that's not within the scope of the accessibility regulations

Older PDFs and other documents

Many of our older PDFs and Word documents do not meet accessibility standards - for example, they may not be structured so they're accessible to a screen reader. This does not meet WCAG 4.1.2 (name, role value).

The accessibility regulations do not require us to fix PDFs or other documents published before 23 September 2018 if they're not essential to providing our services.

Any new PDFs or Word documents we publish will meet accessibility standards.

Older videos

Some of our older videos do not have captions. This fails WCAG 1.2.2 (captions - pre-recorded).

We do not plan to add captions to these older videos because videos published before 23 September 2020 are exempt from meeting the accessibility regulations.

Maps

Our maps are not accessible to screen reader users. We have ensured that essential information included in maps, such as addresses or directions, are available in an accessible format.

Preparation of this accessibility statement

This statement was prepared on 22 September 2020. It was last updated on 15 October 2024.

This website was last tested in July 2024.

The test was carried out by Shaw Trust Accessibility Services. The most viewed pages were tested using automated testing tools by our website team. A further audit of the website was carried out to the WCAG AA standard.