Accessibility statement for www.kent.police.uk

This website sits on the Single Online Home (SOH) platform and uses national templates. The content is a mix of national and local.

National content is managed by the SOH team, local content is managed by the individual forces. Responsibility for the accessibility compliance of the national content sits with the SOH team; individual forces are responsible for the compliance of their local content. 

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 300% without the text spilling off the screen
  • 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)

We’ve also made 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 aren’t fully accessible:

  • Any data visualisation tools such as charts and diagrams are not accessible by screen readers, screen recognition software and other assistive technology. They do not display well on smaller screens including mobiles and tablets. Data visualisation filter options are difficult to operate with a keyboard and the focus order doesn’t always follow a meaningful sequence from top to bottom or left to right. Some focus visible styles are missing which can make it difficult for some users to see their location on the page. Content isn’t structured well and assistive technology may not be able to perceive the information and relationships within the content.
  • Some parts of our forms (such as checkboxes, radio controls and list boxes and combo boxes) are difficult to use with screen readers such as JAWS and voice command software such as Dragon.
  • On some pages we use Google Maps to determine an accurate location, which screen reader users and keyboard users can find difficult to use.
  • The sub navigation links on the home page can be difficult to access to some screen reader software (such as JAWS and VoiceOver). The website search tool or content links offer alternative ways to navigate the website.
  • Some carousel/sliding content may be difficult to understand and operate for screen reader and keyboard users.
  • The website does not provide status messages for screen reader users.
  • When using the enter key to operate form elements, e.g. list boxes, required field validation messages will display before you submit your data.
  • The date format requirement may not be communicated to all screen readers. The date format follows the European date format with forward slash separated numbers e.g. DD/MM/YYYY.
  • Using the Escape key to cancel out of page elements such as dialogue windows or for use with assistive technology menus, will result in a redirect away from the website and form data will be lost.
  • Progress indicators don’t always accurately read out the progress status to screen readers.
  • The skip links cause a keyboard trap in older version of IE and on wide displays the skip links are not always visible against the white background.
  • Information about external links that open in a new window are not communicated to touch screen readers and may cause an unexpected change in context.
  • Some focus visible styles (e.g. on blue buttons and search boxes) do not provide enough contrast from default states or background colours and may be difficult to locate.
  • Embedded YouTube video iframes do not always contain a title and this content may be difficult to perceive for screen reader users.
  • Most older PDF documents aren’t fully accessible to screen reader software.
  • Some content on our website is not available unless JavaScript is enabled e.g. forms and maps and data visualisations.

What to do if you can’t access parts of this website

If you find you can't access content on this site, please tell us about it.

We’re always looking to improve the accessibility of this website. If you find any problems that aren’t listed on this page or think we’re not meeting accessibility requirements, contact us:

Online using our accessibility contact form.

By email: soh-accessibility@met.police.uk

Please note: this is only for logging issues about accessibility. If you'd like to contact us about something else, and you need a response, please use our contact page.

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

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

This website is partially compliant with the Web Content Accessibility Guidelines version 2.1 AA standard, due to the non-compliances listed below.

Non accessible content

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

Non compliance with the accessibility regulations

Data visualisations

  • There are a number of WCAG 2.1 AA non compliances within the data visualisations including:
  • Missing alternative text on graphics. This doesn’t meet success criterion 1.1.1 Non-text Content (Level A).
  • Information and structure is not always conveyed with native, appropriate or semantic HTML elements. This doesn’t meet success criterion 1.3.1 Info and Relationships (Level A).
  • Some content doesn’t have enough contrast with foreground and background colours. This doesn’t meet success criterion 1.4.3 Contrast (Minimum) (Level AA).
  • Text is not always used to convey information rather than images of text. This doesn’t meet success criterion 1.4.5 Images of Text (Level AA).
  • Content doesn’t reflow or respond well on smaller screens or with zoomed displays. This doesn’t meet success criterion 1.4.10 Reflow (Level AA).
  • Tooltip content isn't dismissible, hoverable or persistent. This doesn’t meet success criterion 1.4.13 Content on Hover or Focus (Level AA)
  • Not all data visualisation content is keyboard accessible. This doesn’t meet success criterion 2.1.1 Keyboard (Level A).
  • Filter options can cause keyboard traps. This doesn’t meet Success Criterion 2.1.2 No Keyboard Trap (Level A)
  • The focus order doesn’t always reflect the logical relationships in the content. This doesn’t meet success criterion 2.4.3 Focus Order (Level A).
  • Not all focusable components have focus visible styles. This doesn’t meet success criterion 2.4.7 Focus Visible (Level AA).
  • Some form elements don’t have associated labels. This doesn’t meet success criterion 3.3.2 Labels or Instructions (Level A).

Forms

  • Most forms within the website rely on JavaScript to display and manage data.
  • Progress indicators don’t always accurately read out the progress status to screen readers. This doesn’t meet success criterion 1.3.1 Info and Relationships (Level A)
  • Some parts of our forms (list boxes and combo boxes) are difficult to operate with a keyboard when using a screen reader. This doesn’t meet success criterion 2.1.1 Keyboard (Level A).
  • When using the enter key to operate form elements, e.g. list boxes, required field validation messages will display before you submit your data. This doesn’t meet success criterion 2.1.1 Keyboard (Level A).
  • Form validation and error messages are not read out by some screen readers. This doesn't meet success criterion 3.3.1 Error Identification (Level A)
  • The date format requirement may not be communicated to all screen readers. The date format follows the European date format with forward slash separated numbers e.g. DD/MM/YYYY. This doesn’t meet success criterion 3.3.2 Labels or Instructions (Level A).
  • Some parts of our forms (such as checkboxes, radio controls and list boxes and combo boxes) are difficult or impossible to use with screen readers such as JAWS and voice command software such as Dragon. This doesn’t meet success criterion 4.1.2 Name, Role, Value (Level A).

Maps

  • On some pages we use Google Maps to determine an accurate location, which screen reader users and keyboard users can find difficult or impossible to use. This doesn’t meet success criteria 2.1.1 Keyboard (Level A) and 4.1.2 Name, Role, Value (Level A).
  • Some map buttons and components don’t have focus visible styles. This doesn’t meet success criterion 2.4.7 Focus Visible (Level AA).

Navigation

  • The home page sub navigation links aren’t accessible to screen reader software. This doesn’t meet success criteria 2.1.1 Keyboard (Level A) and 2.4.4 Link Purpose (In Context) (Level A).

Content

Some page content doesn’t meet WCAG 2.1 compliance including:

  • Most PDF documents aren’t fully accessible to assistive technology. They don’t use semantic tags to communicate the information and structure of the document. This doesn’t meet success criteria 1.1.1 Non-text Content, 1.3.1 Info and Relationships, 2.4.1 Bypass Blocks, 2.4.2 Page Titled and 4.1.2 (name, role value).
  • Some carousel/sliding content may be difficult to operate for screen reader and keyboard users. Not all buttons and links have focus visible styles and current slides are not communicated. Carousel paging button automatically initiate a change of context which isn't communicated to screen reader users. These issues don’t meet the following success criteria: 3.2.1 On Focus (Level A), 2.1.1 Keyboard (Level A), 2.1.2 No
  • Keyboard Trap (Level A), 1.3.1 Info and Relationships (Level A) and 2.4.7 Focus Visible (Level AA).
  • Embedded YouTube video iframes do not always contain a title attribute and this content may be difficult to for screen reader users to perceive and access. This doesn’t meet success criteria 2.4.1 Bypass Blocks (Level A) and 4.1.2 Name, Role, Value (Level A).
  • Information about external links that open in a new window are not communicated to touch screen readers and may cause an unexpected change in context. This doesn’t meet success criteria 2.4.4 Link Purpose (In Context) (Level A) and success criterion 3.2.2 On Input (Level A).
  • Some HTML parsing errors may occur in source code especially when copied from external sources. Some duplicate IDs have been identified but are not thought to impact significantly on users. This does not meet success criterion 4.1.1 Parsing (Level A).
  • The website does not provide status messages for screen reader users. This doesn’t meet success criteria 4.1.3 Status Messages (Level AA).

Keyboard operation

  • Some focus visible styles (e.g. on blue buttons and search boxes) do not provide enough contrast from default states or background colours and may be difficult to locate. This doesn’t meet success criterion 1.4.11 Non-Text Contrast (Level AA).
  • The skip links cause a keyboard trap in older version of IE and on wide displays the skip links are not always visible against the white background. This doesn’t meet success criterion 2.1.2 No Keyboard Trap (Level A).
  • Using the Escape key to cancel out of page elements such as dialogue windows or for use with assistive technology menus, will result in a redirect away from the website and form data will be lost. For security and privacy reasons pressing the escape key on any page triggers the 'Leave this site' link shortcut and causes a redirection away from this website. This is in place to give vulnerable users the option to leave the site as quickly as possible. This doesn’t meet success criterion 4.1.2 Name, Role, Value (Level A).

Disproportionate burden

In terms of accessibility compliance, we will consider size, resources and function; the estimated costs and benefits for us in terms of the website audience with disabilities; and the frequency of use and lifespan of this website.

Data visualisation and interactive tools and transactions are currently being reviewed in order to establish if there is a disproportionate burden within the meaning of accessibility regulations.

Data visualisation

Any interactive data visualisations are built and hosted through third party software and ‘skinned’ to look like our website. These tools don’t provide a text alternative (such as a table) to the visual data representation. This doesn’t meet WCAG 2.1 success criterion 1.1.1 (non-text content). However, this third party content is neither funded nor developed by us and is therefore exempt.

Interactive tools and transactions

Some of our interactive forms are difficult to navigate using screen reader and voice command software. For example, because some form controls are missing a ‘label’ tag.

We’ve assessed the cost of fixing the issues with navigation and accessing information, and with interactive tools and transactions. We believe that doing so now would be a disproportionate burden within the meaning of the accessibility regulations.

We will make another assessment when the supplier contract is up for renewal.

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

PDFs and other documents

Many of our older PDFs and Word documents don’t meet accessibility standards - for example, they may not be structured so they’re accessible to a screen reader.

This doesn’t meet WCAG 2.1 success criterion 4.1.2 (name, role value).

Some of our PDFs and Word documents are essential to providing our services. For example, we have PDFs with information on how users can access our services, and forms published as Word documents. By September 2020, we plan to either fix these or replace them with accessible HTML pages.

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

We don’t plan to fix non-essential documents e.g. marketing and advertising materials.

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

How we tested this website

This website was last tested in May 2019, using:

Automated testing

  • The quickest way to catch 20-50% of potential issues.

Usability testing

  • Ask users with real accessibility needs to test the website and learn from their feedback.

Manual testing

  • Using assistive technology tools manually test the website with special focus on components with known challenges.

What we’re doing to improve accessibility

We're working to address the issues outlined above.

We continually monitor the accessibility compliance of our site and have made the fixing and improvement of the site part of our daily digital housekeeping activities.

 

This statement was prepared on 20 September 2019. It was last updated on 20 September 2019.