Accessibility statement for eplanning.norfolk.gov.uk

This accessibility statement applies to eplanning.norfolk.gov.uk.

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:

Pages don't specify the language they are in the code. This means that web browsers and assistive technologies may find it difficult to determine the page language and communicate this to users.
Some pages don't have a page title. This means that users looking at search results, site maps and browser tabs may struggle to identify what the page is about.
Some interactive components are not possible to use or navigate to using typical keyboard commands. This means that users may find it difficult to use the website using keyboard navigation.
Some interactive components on planning application pages don't respond to typical keyboard commands. This makes the content difficult for keyboard navigation users to navigate and may create confusion for screen reader users.
Adjusting the number of results displayed per page on the search results page causes the page to refresh. This may disorientate users, particularly visually impaired people.
Some links that help keyboard navigation users navigate to particular sections of pages have link text that doesn't accurately describe where the link will take the user. This may disorientate users, particularly visually impaired people.
The accessible name for some interactive components, like links and buttons, doesn't match their visible text. This means that some speech recognition software users may struggle to use them.
The accessible name for some interactive components doesn't accurately describe their purpose. This means that some assistive technology users may struggle to use them.
Some interactive components have missing or inaccurate information about them in the code. This means that some assistive technology users may struggle to use them.
Some form fields on comments on planning application pages do not support autocomplete. This means that users who rely on autocomplete may struggle to use the form.
Some error and status messages on comment on planning application pages are not coded correctly. This means that they will not be read out automatically by a screen reader when they appear, and some users may miss them.
The alt text for the Norfolk County Council logo in the website header doesn't communicate accurately that it will take users to the Norfolk County Council website home page.
The date picker icons and placeholder text on some forms have insufficient colour contrast. This means that some users may struggle to see them.
Some buttons change colour to show that the user is hovering over them with a mouse. The difference between the colours is small, which means some users may not notice the colour change.
Some interactive components change colour to show that the user has navigated to them using a keyboard or selected them. The difference between the colours is small, which means some users may not notice the colour change or be able to see them.
Links in the 'Services' menu in the website header may be difficult to see for people using smaller screens or zooming in.
The 'Facebook' link the website footer may be difficult to read for people using text spacing adjustment.

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 mawp@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).

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

Page language

On all pages, the page HTML does not have a 'lang' attribute. This means that web browsers and assistive technologies may find it difficult to determine the page language and communicate this to users.

This fails WCAG 3.1.1.

Page title

Search results, planning application and comment on planning application pages do not have a page title. This means that users looking at search results, site maps and browser tabs may struggle to identify what the page is about.

This fails WCAG 2.4.2.

Keyboard navigation

On all pages, once a user navigates into the breadcrumb links using a keyboard (tab key) they can't navigate back to the linked NCC logo or 'Services' menu using the tab + shift keys.
On all pages, the user must press the enter key or spacebar twice to reveal the 'Services' menu in the header.
On the advanced search page, the user can't submit the form using the 'Search' button with a keyboard using the enter key. The only way to submit the form is to click on the 'Search' button using a mouse.
On comment on planning application pages, when a user tabs to the 'Reset form' button and uses the enter key to activate the button, it does not reset the form. The only way to use the button to reset the form is to click on it using a mouse.

This fails WCAG 2.1.1.

Focus order

On planning applications pages, the tab widget has a focus order that doesn't adhere to the keyboard interaction specified in W3C's tabs pattern:

When using the tab key to navigate into the tab list, this always moves focus to the tab after the active tab instead of the active tab
When focus moves into the tab list, the tab panel that relates to the tab that has focus does not display automatically or when the user presses the Enter key or spacebar. To cause the tab pane to appear, the user must navigate away to a different tab then back to the tab again.
When using the tab + shift keys to navigate back into the tab list, this always moves focus to the last ('Appeals') tab instead of the last focusable element in the active tab panel (if there is one) or the active tab (if there aren't any focusable elements in the active tab panel)
When there are focusable elements in the active tab panel (eg. the 'Documents' tab panel) and focus is in the tab list, using the tab key does not move focus to the first focusable element in the active tab panel. It instead moves focus to outside (after) the tab panel. To navigate to focusable elements in the active tab panel, the user must tab to outside (after) the tab panel, the use the tab + shift keys to navigate back into the active tab panel.

On planning applications pages, the grid (in the 'Documents' tab panel) has a focus order that doesn't adhere to the keyboard interaction specified in W3C's grid pattern. This is because, once the user has moved focus into the grid using the tab key, they can't use the arrow keys to navigate around the grid. Instead, they must use the tab key.

This fails WCAG 2.4.3.

User input

On the search results page, using the select form field (dropdown list) to change the number of results per page submits the form automatically and causes the page to refresh. This is not expected behaviour and the user is not warned this will happen.

This fails WCAG 3.2.2.

Link purpose

On the advanced search page, a 'Skip to planning appeals section' link appears when the user tabs through the page. Activating the link takes the user back to the top of the page instead of to the planning appeals section.
On the advanced search page, a 'Back to the planning section' link appears when the user tabs through the page. Activiating the link takes the user back to the 'Planning applications, minerals and waste' section of the form. This isn't made clear by the link text.
On planning application pages, a 'Skip to the tab headings.' link appears when the user tabs through the page. Activating the link takes the user back to the top of the page instead of to the tabs.
On planning application pages, a 'Skip to download all button.' link appears when the user tabs through the 'Documents' tab panel. There is no 'Download all' button, and activating the link takes the user back to the top of the page.
On comment on planning application pages, a 'Skip to comment details section.' link appears when the user tabs through the page. Activating the link takes the user to some skip links before the 'Comment details' section instead of to the beginning of the 'Comment details' section.
On comment on planning application pages, a 'Back to the your details section.' link appears when the user tabs through the page. Activating the link takes the beginning of the main page content instead of to the beginning of the 'Your details' section.

This fails WCAG 2.4.4.

Label in name: links

On all pages, the page footer contains a linked INTRAN logo with the visible text 'INTRAN communication for all'. Some of the visible text is missing from the linked logo's accessible name ('INTRAN interpretation and translation services').
On the search planning applications page, the four links directly below the keyword search have visible text that is not included in the link's accessible name. For example, the visible text for the first link is 'View planning applications registered in the last 7 days'. However, the link's accessible name is 'Search for applications that have been received in the last 7 days'.

This fails WCAG 2.5.3.

Descriptive labels

On the advanced search page, the accessible label for each date picker button is 'Choose date'. This doesn't make it sufficiently clear which field each button relates to (ie. which fields it enables you to choose a date for).
On the comment on planning application pages, there is a span element after the 'Number of signatures' text input in the HTML with an aria-label attribute. ARIA rules state that an aria-label attribute cannot be used on a span with no valid role attribute.
On the comment on planning application pages, the instructions relating to the 'Comments' text field (the instructions 'Please enter no more...' and the character counter) are not programmatically associated with the 'Comments' text field.
On the comment on planning application pages, the label and instructions relating to the 'Attach files' input (the label 'Attachments (optional)' and the instructions below the input) are not programmatically associated with the 'Attach files' input.
On the comment on planning application pages, if a user attaches multiple files, the accessible label for each file description field is 'Text input: description' and the accessible label for each button used to remove each attachment is 'Button: remove document'. This doesn't make it sufficiently clear which description field and remove button relates to which file.

This fails WCAG 3.3.2.

Label in name: widgets

On the advanced search page, the accessible labels for some of the radio buttons do not include all visible text. For example, the visible label for the third radio button is 'County council Development - applications such as schools, libraries, roads, community hubs and fire stations.' but the accessible label is 'Radio input: Search county council applications'.
On the advanced search page, the 'Development type' label above the three radio buttons functions as a label for all three radio buttons but is not programmatically associated with them.
On planning application pages, the two download buttons have the visible text 'Download selected files'. The accessible names for these buttons is 'Download selected documents', which does not include all the visible text.
On comment on planning application pages, the checkbox to receive replies by email has the visible label 'I would like to receive replies via this email'. The accessible label for the checkbox is 'Checkbox input: Receive replies by email', which does not include all the visible label text.
On comment on planning application pages, the number of signatures text field has the visible label 'Number of signatures (optional)'. The accessible label for the text field is 'Text input: Number of signatures', which does not include all the visible text.

This fails WCAG 1.3.1 and WCAG 2.5.3.

Widget design

On all pages, the 'Services' button in the site header has the attribute 'aria-expanded'. The value for the attribute is always set to 'true', even when the menu the button reveals/hides is hidden.

On the advanced search page, the date picker buttons open a dialog showing an interactive date picker. It is nested in a container with the attribute and value 'role="dialog"' but it does not have an accessible name.

On planning application pages, the tab widget does not support the ARIA roles, states and properties specified by W3C's tabs pattern:

The elements that contains the content panel for each tab do not have the attribute and value 'role="tabpanel"' or an 'aria-labelledby' attribute that refers to the relevant tab.
The element with the attribute and value 'role="tablist"' does not have an accessible label.
Each element with the attribute and value 'role="tab"' does not have an 'aria-controls' attribute that references the relevent tabpanel element.
The selected tab element has an aria-selected value of 'false' instead of 'true'.

On planning application pages, the grid (in the 'Documents' tab panel) does not support the ARIA roles, states and properties specified by W3C's grid pattern:

The element that contains the grid does not have the attribute and value 'role="grid"' or use 'aria-describedby' to reference the instructions text above the grid ('To download a selection of individual documents...').
'aria-sort' is not used on table header elements that provide a sort function.

On comment on planning application pages, if a user attaches a file, a button is shown that users can use to remove the attachment. It is coded using an anchor element, but it functions as a button and does not include the attribute and value 'role="button"'.

This fails WCAG 4.1.2.

Autocomplete

On comment on planning application pages, the 'Name', 'Address' and 'Email' fields do not have valid autocomplete values. This means that some users would struggle to use autocomplete to complete the form.

This fails WCAG 1.3.5.

Status messages

On comment on planning applications pages, the error messages that appear when a user does not complete certain form fields correctly are not presented in containers with the attribute and value 'role="alert"'.
On comment on planning applications pages, when a user attaches files to the form they are shown a status message 'Documents selected.'. This is not presented in a container with attribute and value 'role="status"'.

This fails WCAG 4.1.3.

Text alternative

On all pages, the alt text for the linked logo image of the Norfolk County Council logo in the site header is 'Norfolk logo'. This doesn't accurately describe the image or where the link takes the user.

This fails WCAG 1.1.1.

Colour contrast

On the advanced search page, the icons on the date picker buttons are a light blue that does not contrast at least 3:1 with the white page background.
On comment on planning application pages, the light grey placeholder text in the file description text field contrasts less that 4.5:1 with the white background colour.

This fails WCAG 1.4.11 and WACG 1.4.3.

Colour as meaning

On the search results page, when the page links styled to look like buttons (eg. '1', '2', 'Next', 'Last') change between normal and hover states, the only visible indication of this state change is a change of background colour between white and grey. The colour contrast between the white and grey is less than 3:1.
On planning application pages, when the tabs change between normal and hover states, the only visible indication of this state change is a change of background colour between light grey and dark grey. The colour contrast between the light grey and dark grey is less than 3:1.

This fails WCAG 1.4.1.

State changes

On all pages, the yellow border which shows an interactive component is in focus or selected states does not contrast sufficiently with the white or grey page backgrounds. It also relies on colour change alone to communicate that the state has changed.

This fails WCAG 1.4.11 and WCAG 1.4.1.

Reflow

On all pages, at screen resolution 1280 x 1024 and browser zoom 400%, when the user opens the 'Services' menu, some of the link text in the menu overlaps, which makes it hard to read. The user also must scroll horizontally as well as vertically to see all the link text.

This fails WCAG 1.4.10.

Text spacing

On all pages, when adjusting text spacing, the 'k' in 'Facebook' in the site footer is cut off.

This fails WCAG 1.4.12.

The content is not within the scope of the accessibility regulations

Third party content

We are not responsible for the accessibility of third party content that is not funded or developed by us or is not under our control.

This includes application documents that are submitted by third parties to support their planning applications.

Preparation of this accessibility statement

This statement was prepared on 23 February 2022. The statement was last reviewed on 28 March 2025.

This website was last tested in March 2025. Norfolk County Council's Digital Customer Experience Team carried out the test.

We tested the website eplanning.norfolk.gov.uk using automated and manual tests. We used:

Accessibility Insights for Web browser extension
Browser developer tools
Web Developer browser extension
Stylus browser extension
Colourcontrast.cc browser extension
NVDA

We used a sample-based approach to auditing, based on the Website Accessibility Conformance Evaluation Methodology (WCAG-EM).