Accessibility statement for the City of York Safeguarding Children Partnership website
This accessibility statement applies to City of York Safeguarding Children Partnership website: www.saferchildrenyork.org.uk and covers all users accessing online services which don't meet accessibility standards.
Proposed statement relating to
This website is run by The City of York Safeguarding Partnership. We want as many people as possible to be able to use this website. For example, that means you should be able to:
- zoom in up to 300% without the text spilling off the screen
- navigate most of the website using just a keyboard
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 are not fully accessible:
- you cannot modify the line height or spacing of text
- most older PDF documents are not fully accessible to screen reader software
- live video streams do not have captions
- some of our online forms are difficult to navigate using just a keyboard
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 5 working days.
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, contact the CYSCP Business Unit: email@example.com
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
The City of York Safeguarding Partnership 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.
Some parts of our online services are non-compliant, meaning they don't meet accessibility standard 'WCAG 2.1 AA', in these cases:
We are working with internal teams who administer the systems, and with external suppliers, to improve accessibility standards
Due to the amount of issues and the complexity of fixes, we'll continue to update this statement as we identify and resolve areas of non-compliance.
- There may be some failure conditions where duplicate ID errors are known to cause problems for assistive technologies when they are trying to interact with content. Duplicate values of type ID can be problematic for user agents that rely on this attribute to accurately convey relationships between different parts of content to users - this relates to F17 - Failure of Success Criterion 1.3.1 and 4.1.1 due to insufficient information in DOM to determine one-to-one relationships (e.g., between labels with same id) in HTML
- This failure condition may occur on some pages when a link contains only non-text content, such as an image, and that link cannot be identified by an accessible name. The accessible name for a link is defined according to the Accessible Name Calculation.
This relates to error code F89 - Failure of Success Criteria 2.4.4, 2.4.9 and 4.1.2 due to using null alt on an image where the image is the only content in a link
- There may be some failure conditions where id attributes are not unique on a Web page and can cause errors that are known to cause problems for assistive technologies when they are trying to parse content that has the same id attribute on different elements.
this relates to H93: Ensuring that id attributes are unique on a Web page
- There may be some failure conditions where techniques have failed to ensure that sections have headings that identify them. Success Criterion 1.3.1 requires that the headings be marked such that they can be programmatically identified.
This relates to error code G141.
- There may be some failure conditions failing to allow for the technique to use HTML and XHTML according to their respective specifications. Technology specifications define the meaning and proper handling of features of the technology. Using those features in the manner described by the specification ensures that user agents, including assistive technologies, will be able to present representations of the feature that are accurate to the author's intent and interoperable with each other. this relates to error H88: Using HTML according to spec
- Some pages or content may contain key errors that are known to cause problems for assistive technologies when they are trying to parse contents. Well-formedness is checked by parsing the document with a conforming XML parser and checking if the validation report mentions well-formedness errors. Every conforming XML parser is required to check well-formedness and stop normal processing when a well-formedness error is found (a conforming XML parser does not need to support validation). H75: Ensuring that Web pages are well-formed
- There may be some occurrences of mark-up languages not used in a way that fully conforms to their specifications, all of the requirements in 4.1.1 are met. Therefore, while fully conforming to specifications is not required to conform to WCAG 2.0, it is a best practice and is sufficient to meet Success Criterion 4.1.1.
This relates to error G192: Fully conforming to specifications
- There may be some web pages that contain ambiguities in Web pages that often result from code that does not validate against formal specifications. Each technology's mechanism to specify the technology and technology version is used, and the Web page is validated against the formal specification of that technology. If a validator for that technology is available, the developer can use it.
Validation will usually eliminate ambiguities (and more) because an essential step in validation is to check for proper use of that technology's markup (in a markup language) or code (in other technologies). Validation does not necessarily check for full conformance with a specification but it is the best means for automatically checking content against its specification. This technique relates error G134 and effects Success Criterion 4.1.1: Parsing
- There may be some failure conditions where the purpose of a link by providing descriptive text as the content of the a element is unavailable. The description lets a user distinguish this link from other links in the Web page and helps the user determine whether to follow the link. The URI of the destination is generally not sufficiently descriptive. this relates to error H30: Providing link text that describes the purpose of a link for anchor elements
- There may be some failure conditions in displaying a descriptive title for a PDF document. This can be specified for assistive technology by using the /Title entry in the document information dictionary and by setting the DisplayDocTitle flag to True in a viewer preferences dictionary. This is typically accomplished by using a tool for authoring PDF.
PDF18: Specifying the document title using the Title entry in the document information dictionary of a PDF document
- There may be some web pages that contain failures to identify examples of mark-up errors in element tags that could cause assistive technology to be unable to generate a satisfactory model of the page. Different user agents may implement different heuristics to recover from errors, resulting in inconsistent presentations of the page between user agents.
This failure relates to:Success Criterion 4.1.1 (Parsing)
F70: Failure of Success Criterion 4.1.1 due to incorrect use of start and end tags or attribute mark-up
- Some web pages may contain failures to avoid situations in which synchronized media alternatives are not labeled with the text for which they are alternatives. Synchronized media alternatives provide enhanced access to users for whom synchronized media is a more effective format than text. Since they are alternatives to text, they do not need themselves to have redundant text alternatives. However, they need to be clearly labelled with the text for which they substitute, so users can find them and so users who normally expect text alternatives to synchronized media know not to look for them.
This relates error code H74 to WCAG 2.1 Failure of Success Criteria 4.1.1 - Parsing (A)
- There may be some PDF documents that contain errors to ensure that users can navigate through content in a logical order that is consistent with the meaning of the content. Correct tab and reading order is typically accomplished using a tool for authoring PDF.
For sighted users, the logical order of PDF content is also the visual order on the screen. For keyboard and assistive technology users, the tab order through content, including interactive elements (form fields and links), determines the order in which these users can navigate the content. The tab order must reflect the logical order of the document.
This technique relates to PDF3: Ensuring correct tab and reading order in PDF documents
- There may be some web pages that contain failures in describing the purpose of a link in the text of the link. The description lets a user distinguish this link from links in the Web page that lead to other destinations and helps the user determine whether to follow the link. The URI of the destination is generally not sufficiently descriptive.
This technique relates to G91: Providing link text that describes the purpose of a link
- There may be some PDF documents that contain errors to ensure specification of a document's default language by setting the /Lang entry in the document catalog. This is normally accomplished using a tool for authoring PDF.
This relates to Success Criterion 3.1.1 (Language of Page)- PDF16: Setting the default language using the /Lang entry in the document catalog of a PDF document.
The content listed below is non-accessible for the following reasons:
- Some images do not have a text alternative, so people using a screen reader cannot access the information. This fails WCAG 2.1 success criterion 1.1.1 (non-text content).
- We plan to add text alternatives for all images by July 2021. When we publish new content we’ll make sure our use of images meets accessibility standards.
Non-compliance with the accessibility regulations
Refer to the above section.
Navigation and accessing information
There’s no way to skip the repeated content in the page header (for example, a ‘skip to main content’ option).
It’s not always possible to change the device orientation from horizontal to vertical without making it more difficult to view the content.
It’s not possible for users to change text size without some of the content overlapping.
Interactive tools and transactions
Some of our interactive forms are difficult to navigate using a keyboard. For example, because some form controls are missing a ‘label’ tag.
Our forms are built and hosted through third party software and ‘skinned’ to look like our website.
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.
Content that’s not within the scope of the accessibility regulations
PDFs and other documents
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 do not require us to fix PDFs or other documents published before 23 September 2018 if they’re not essential to providing our services. For example, we do not plan to fix [example of non-essential document].
Any new PDFs or Word documents we publish will meet accessibility standards.
We do not plan to add captions to live video streams because live video is exempt from meeting the accessibility regulations.
What we’re doing to improve accessibility
We are working with City of York Council and Sitekit to improve the accessibility on the CYSCP website.
Preparation of this accessibility statement
This statement was prepared on 9th November 2020. It was last reviewed on 22nd February 2021.
This website was last tested on January 2021. The test was carried out by the City of York Council.