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: 16 January 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/

  • Link purpose: This fails WCAG 2.0 A 2.4.4 - Link purpose (in context). The purpose of a link should be clear from the text inside the link. Links like "learn more" are not helpful to users with assistive technology.
  • Image in link alt text: This fails WCAG 2.0 A 1.1.1 - Non-text content. When an image is the only content of a link, it should specify alternative text, via an alt attribute. The alternative text should describe the purpose of the link.
  • 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.
  • 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.
  • 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 above and aim to provide a further update in April 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.

Current status

We are working with our supplier to identify solutions to the issues detailed and aim to provide a further update in April 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 April 2025.

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

  • Semantic links: Fails WCAG 2.0 A 1.3.1 - Info and relationships. Lists (e.g., <ul> or <ol>) should only contain list items (<li>) as a direct descendant to ensure that screen readers can accurately report the amount of items contained in the list.
  • 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 above and aim to provide a further update in April 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.
  • Link purpose: This fails WCAG 2.0 A 2.4.4 - Link purpose (in context). The purpose of a link should be clear from the text inside the link. Links like "learn more" are not helpful to users with assistive technology.
  • 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.
  • Image in link alt text: This fails WCAG 2.0 A 1.1.1 - Non-text content. When an image is the only content of a link, it should specify alternative text, via an alt attribute. The alternative text should describe the purpose of the link.
  • 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.

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 April 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: Fails to comply with WCAG 1.3.5, 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.

Current status

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

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

  • Duplicate IDs: Fails on WCAG 2.0 A 4.1.1. All ID attributes on a page must be unique, or accessible technologies used by the page can stop working.
  • 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: Fails to comply with WCAG 1.3.5, 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: 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 April 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.
  • 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.
  • Programmatic field purpose: Fails to comply with WCAG 1.3.5, 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 April 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: 16 January 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.