Cookies

We use some essential cookies to make this website work.

We’d like to set additional cookies to understand how you use our website so we can make improvements.

We also use cookies set by other sites to help us deliver content from their services.

Accept additional cookies Reject additional cookies View Cookies

Strictly Necessary Cookies

These cookies cannot be disabled

These cookies are necessary for the website to function and cannot be switched off. They are normally set in response to your interactions on the website e.g. logging in etc.

Cookies:
  • .ASPXANONYMOUS
  • .DOTNETNUKE
  • __RequestVerificationToken
  • authentication
  • dnn_IsMobile
  • language
  • LastPageId
  • NADevGDPRCookieConsent_portal_0
  • userBrowsingCookie

Performance Cookies

Turn Performance cookies on/off

These cookies allow us to monitor traffic to our website so we can improve the performance and content of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited or how you navigated around our website.

Cookies:
  • __utma
  • __utmb
  • __utmc
  • __utmt
  • __utmz
  • _ga
  • _gat
  • _gid

Functional Cookies

Turn Functional cookies on/off

These cookies enable the website to provide enhanced functionality and content. They may be set by the website or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.

Cookies:
  • nmstat
  • textSize

Targeting Cookies

Turn Targeting cookies on/off

These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.

Cookies:

Currently we are not utilizing these types of cookies on our site.

Change cookie settings Close
Skip to main content

Accessibility statement

Last updated: 30 April 2025

This accessibility statement applies to the Waverley website and other websites we use to deliver our services.

This website is run by Waverley Borough Council. We want as many people as possible to be able to use this website.  For example, this means you should be able to:

  • navigate most of the website using a keyboard
  • navigate most of the website using speech recognition software
  • listen to most of the website using a screenreader
  • change the font size of the text without the text spilling off the screen

We’ve also tried to make the website text as simple as possible to understand.

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

How accessible this website is

We know some parts of this website are not fully accessible:

  • older PDF documents and some submitted by third parties are not fully accessible to screen reader software
  • live video streams  and videos of our council meetings do not have captions
  • some online forms and partner website we use to deliver our services are difficult to navigate using just a keyboard
  • online maps are not accessible to screen reader software.

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:

We’ll consider your request and get back to you in ten working days.

If you cannot view the map on our ‘Contact us’ page, call 01483 523333 or email us general.enquiries@waverley.gov.uk for directions.

Reporting accessibility problems with this website

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, please contact the Website Manager:

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

Visiting us in person

For people who have hearing aids, we have a standard hearing loop in reception and infra-red loops in the council chamber and our committee meeting rooms.

Please email general.enquiries@waverley.gov.uk to find out more.

Technical information about this website’s accessibility

Waverley Borough 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 version 2.2 AA standard, due to the non-compliances and exemptions listed below.

September 2024 update: Following the introduction of new success criteria with WCAG 2.2, we carried out automated testing on our public-facing websites/digital services, which highlighted some non-compliances with this and previous guidelines (2.0, 2.1) requiring further investigation.

We are currently engaging with suppliers to understand what steps need to be taken to resolve these issues, and will provide the latest updates via this statement.

Non-accessible content

The content listed is non-accessible for the following reasons.

  • some older PDF documents, and some supplied by other parties, are not fully accessible to screen reader software
  • videos of council meetings do not have captions
  • our planning maps and Google maps are not accessible.

Non-compliances

Select the relevant heading to see specific non-compliance issues.

https://www.waverley.gov.uk/

  • Form control contrast: This fails WCAG 2.1 AA 1.4.11 - Non-text contrast. Form controls must appear sufficiently distinct from their surroundings, so that people with visual impairments are still able to clearly see them.
  • Form submit button: This fails WCAG 2.0 A 3.2.2 - On Input. Forms should always contain a submit button, otherwise some people using accessible technologies may not be able to submit the form.
  • Links with different destinations: This fails WCAG 2.0 A 2.4.4 - Link purpose in context. Screen reader users will see links on a page listed without context, so you should ensure the same link text is not used to point to different web addresses.
  • Screen reader links: This fails WCAG 2.0 A 4.1.2 - Name, role, value. Links must be defined in a specific way to be accessed by screen readers, which are used by blind and the partially-sighted.
  • Semantic links: This fails WCAG 2.0 A 1.3.1 - Info and relationships. Lists of related items should be written semantically as a list.

Current status

We are working with our supplier to identify solutions to the issues detailed and aim to provide a further update in August 2025.

https://modgov.waverley.gov.uk

  • Missing anchor: Fails WCAG 2.0 A 2.4.1 - Providing link with context. Do not link to an anchor on the page that does not exist. For example: linking to content without a valid destination.
  • Missing ARIA label IDs: Fails WCAG 2.0 A 1.3.1 - Labels and instructions. When specifying accessible names via aria-labelledby, ensure that the label elements exist.
  • Table headers: Fails WCAG 2.0 A 1.3.1 - Info and relationships. Tables which contain information should have clear headers defined.
  • Adjacent links: Fails WCAG 2.0 A 1.1.1. Two adjacent links should not point to the same destination. You almost always want to combine the two links.
  • Links with different destinations: This fails WCAG 2.0 A 2.4.4 - Link purpose. Screen reader users will see links on a page listed without context, so you should ensure the same link text is not used to point to different web addresses.
  • Interactive component distance: This fails WCAG 2.2 AA 2.5.8 - Target size - Target size (minimum). All interactive components on a page, such as buttons or menus, should be far enough apart from other interactive areas, to avoid them being used by mistake.
  • Text contrast: This fails WCAG 2.0 AA 1.4.3 - Contrast (Minimum). To comply with WCAG AA, the colour of text must sufficiently contrast with its background color, so that people with moderate visual impairments can read it.
  • Form control contrast: This fails WCAG 2.1 AA 1.4.11 - Non-text contrast. Form controls must appear sufficiently distinct from their surroundings, so that people with visual impairments are still able to clearly see them.

Current status

We are working with our supplier to identify solutions to the issues detailed and aim to provide a further update in August 2025.

https://wav-wrp.whitespacews.com/#

  • Programmatic field purpose: Fails on WCAG 2.1 AA 1.3.5 - Identify input purpose. To comply with WCAG 2.1, fields must identify what their purpose is programmatically. If done correctly, this allows browsers to help users fill in forms with known information, such as their name and email address.
  • Duplicate IDs: Fails on WCAG 2.0 A 4.1.1 - Parsing. All ID attributes on a page must be unique, or accessible technologies used by the page can stop working.

Current status

We are working with our supplier to identify solutions to the issues detailed and aim to provide a further update in August 2025.

https://clcnewbuild.commonplace.is/

  • Adjacent links: This fails WCAG 2.0 A 2.4.4 - Link purpose (in context). Two adjacent links should not point to the same destination. You almost always want to combine the two links.
  • Semantic links and lists: This fails WCAG 2.0 A 1.3.1 - Info and Relationships. Lists of related items should be written semantically as a list.
  • Text contrast: This fails WCAG 2.0 AA 1.4.3 - Contrast (Minimum). To comply with WCAG AA, the colour of text must sufficiently contrast with its background color, so that people with moderate visual impairments can read it.
  • Programmatic field purpose: Fails to comply with WCAG 1.3.5 - Identify input purpose. Fields must identify what their purpose is programmatically. If done correctly, this allows browsers to help users fill in forms with known information, such as their name and email address.
  • Form control contrast: This fails WCAG 2.1 AA 1.4.11 - Non-text contrast. Form controls must appear sufficiently distinct from their surroundings, so that people with visual impairments are still able to clearly see them.
  • Field labels: This fails WCAG 2.0 A 1.3.1 - Info and relationships. People using screen readers are not able to see the layout of a form. To make forms accessible, they must define explicit text labels for each form control.
  • Interactive component distance: This fails WCAG 2.2 AA 2.5.8 - Target size (Minimum). All interactive components on a page, such as buttons or menus, should be far enough apart from other interactive areas, to avoid them being used by mistake.
  • Form submit button: This fails WCAG 2.0 A 3.2.2 - On Input. Forms should always contain a submit button, otherwise some people using accessible technologies may not be able to submit the form.
  • Screen reader links: This fails WCAG 2.0 A 4.1.2 - Name, Role, Value. Links must be defined in a specific way to be accessed by screen readers, which are used by blind and the partially-sighted.
  • Duplicate IDs: Fails on WCAG 2.0 A 4.1.1 - Parsing. All ID attributes on a page must be unique, or accessible technologies used by the page can stop working.

Current status

We are working with our supplier to identify solutions to the issues detailed and aim to provide a further update in August 2025.

https://planning360.waverley.gov.uk:4443/planning/

  • Interactive component distance: This fails WCAG 2.2 AA 2.5.8 - Target size. The target size (minimum), where all interactive components on a page, such as buttons or menus, should be far enough apart from other interactive areas, to avoid them being used by mistake.
  • Form submit button: Fails WCAG 2.0 A 3.2.2 - On input. Forms should always contain a submit button, otherwise some people using accessible technologies may not be able to submit the form.
  • Missing anchors: This fails WCAG 2.0 A 2.4.1 -On input. Do not link to an anchor on the page that does not exist. For example: linking to #content without a valid destination.
  • Programmatic field purpose: Fails to comply with WCAG 1.3.5 - Identify input purpose, fields must identify what their purpose is programmatically. If done correctly, this allows browsers to help users fill in forms with known information, such as their name and email address.
  • Missing H1: Fails with WCAG 2.4.6 - Headings. Every page should have a clearly defined heading, known as a ""H1"" (Heading 1). A H1 is the main heading of the page. It helps accessibility by allowing uses to skip to the main content of the page. It helps all users identify what the page is about. 

We are working with our supplier to identify solutions to the issues detailed and aim to provide a further update in August 2025.

https://apps.adelante.co.uk/SmartPay/Waverley/pay4/

Current status

We are working with our supplier to identify solutions to the issues detailed above and aim to provide a further update in August 2025.

https://waverley-central.oncreate.app/w/webpage/welcome

  • Text contrast: This fails WCAG 2.0 AA 1.4.3 - Contrast (Minimum). To comply with WCAG AA, the colour of text must sufficiently contrast with its background color, so that people with moderate visual impairments can read it.
  • Semantic links: This fails WCAG 2.0 A 1.3.1 - Info and relationships. Lists of related items should be written semantically as a list.
  • Heading text: This fails WCAG 2.0 A 1.3.1 - Info and relationships. Heading elements (<h1>, <h2>, ...) must contain some machine-readable text content.
  • Form submit button: This fails WCAG 2.0 A 3.2.2 - On Input. Forms should always contain a submit button, otherwise some people using accessible technologies may not be able to submit the form.
  • Form control contrast: This fails WCAG 2.1 AA 1.4.11 - Non-text contrast. Form controls must appear sufficiently distinct from their surroundings, so that people with visual impairments are still able to clearly see them.
  • Programmatic field purpose: This fails WCAG 2.1 AA 1.3.5 - Identify input purpose. Fields must identify what their purpose is programmatically. If done correctly, this allows browsers to help users fill in forms with known information, such as their name and email address.
  • Missing H1: Fails with WCAG 2.4.6. Every page should have a clearly defined heading, known as a ""H1"" (Heading 1). A H1 is the main heading of the page. It helps accessibility by allowing uses to skip to the main content of the page. It helps all users identify what the page is about.
  • Screen reader links: This fails WCAG 2.0 A 4.1.2 - Name, Role, Value. Links must be defined in a specific way to be accessed by screen readers, which are used by blind and the partially-sighted.
  • Field labels: This fails WCAG 2.0 A 1.3.1 - Info and relationships. People using screen readers are not able to see the layout of a form. To make forms accessible, they must define explicit text labels for each form control.
  • Fieldset grouping: This fails WCAG 2.0 A 1.3.1 - Info and relationships. Radio buttons or check boxes with the same name attribute must be contained within a fieldset element.
  • Duplicate IDs: This fails WCAG 2.0 A 4.1.1 - Parsing. All ID attributes on a page must be unique, or accessible technologies used by the page can stop working.

Current status

We are working on solutions for the issues detailed above, and aim to provide a further update in August 2025.

https://ats-waverley.jgp.co.uk/vacancies

  • Form control contrast: This fails WCAG 2.1 AA 1.4.11 - Non-text contrast. Form controls must appear sufficiently distinct from their surroundings, so that people with visual impairments are still able to clearly see them.
  • Programmatic field purpose: This fails WCAG 2.1 AA 1.3.5 - Identify input purpose. Fields must identify what their purpose is programmatically. If done correctly, this allows browsers to help users fill in forms with known information, such as their name and email address.
  • Links with different destinations: This fails WCAG 2.0 A 2.4.4 - Link purpose (in context). Screen reader users will see links on a page listed without context, so you should ensure the same link text is not used to point to different web addresses.
  • Valid label IDs for fragments: This fails WCAG 2.0 A 1.3.1 - Info and relationships. Labels with a for attribute should point to a unique ID of a labelable control that is used within the document fragment.

Current status

We are working with our supplier to identify solutions to the issues detailed and aim to provide a further update in August 2025.

waverley.inconsult.uk

  • Form control contrast: This fails WCAG 2.1 AA 1.4.11 - Non-text contrast. Form controls must appear sufficiently distinct from their surroundings, so that people with visual impairments are still able to clearly see them.
  • Programmatic field purpose: This fails WCAG 2.1 AA 1.3.5 - Identify input purpose. Fields must identify what their purpose is programmatically. If done correctly, this allows browsers to help users fill in forms with known information, such as their name and email address.
  • Semantic links: This fails WCAG 2.0 A 1.3.1 - Info and Relationships. Lists of related items should be written semantically as a list.

Current status

We are working with our supplier to identify solutions to the issues detailed and aim to provide a further update in August 2025.

https://www.councilparking.org/waverley/pages/OnlineChallengeEntry.aspx

Current status

No issues found. We will review status in August 2025.

https://www.waverleyhomechoice.org.uk/

  • Links with different destinations: This fails WCAG 2.0 A 2.4.4 - Link purpose (in context). Screen reader users will see links on a page listed without context, so the same link text should not be used to point to different web addresses.
  • Form control contrast: This fails WCAG 2.1 AA 1.4.11 - Non-text contrast. Form controls must appear sufficiently distinct from their surroundings, so that people with visual impairments are still able to clearly see them.
  • Programmatic field purpose: This fails WCAG 2.1 AA 1.3.5 - Identify input purpose. Fields must identify what their purpose is programmatically. If done correctly, this allows browsers to help users fill in forms with known information, such as their name and email address.
  • Field labels: This fails WCAG 2.0 A 1.3.1 - Info and relationships. People using screen readers are not able to see the layout of a form. To make forms accessible, they must define explicit text labels for each form control.

Current status

We are working with our supplier to identify solutions to the issues detailed above and aim to provide a further update in August 2025.

https://www.surreylgrhub.org/

Current status

No issues found. We will review the status in August 2025.

Disproportionate burden

Regarding the sites listed below, we have engaged with the suppliers since the issues were first identified in the relevant accessibility check(s) and worked through options to fix them.

However, having assessed the costs involved – both in terms of system updates/upgrades and officer time – we believe that doing so now would be a disproportionate burden within the meaning of the accessibility regulations.

We are working to ensure accessibility is a key criteria for any third party site or system we use to deliver our online services.

Content outside the scope of the accessibility regulations

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 documents we produce are designed with accessibility in mind and checked for compliance before being published online. 

Preparation of this accessibility statement

  • Statement prepared: 13 January 2022
  • Last reviewed: 25 April 2025

This website was initially tested between 15 - 23 December 2021. The test was carried out by Smarter Digital Services (SDS).

SDS used a combination of semi-automated evaluation tools and manual testing on a variety of templates and pages. 

We chose a variety of templates and pages on our main website and other websites we use to deliver our services to get a good sample of content and the different types of templates used.  

You can read the full accessibility audit report.