Accessibility Statement
Proposal for a Koha community Accessibility Statement
Started at KohaCon23
Examples of existing Koha Opac statements
Examples of templates
- PTFS Europe Koha Opac template
- UK government sample accessibility statement
Proposed template accessibility statement (draft)
Accessibility statement for Koha Library Catalogue (OPAC)
This accessibility statement applies to latest version of the uncustomised Koha Library Catalogue as downloaded from koha-community.org.
This website is run by [name of organisation]. 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 200% 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.
How accessible this website is
[Note: use this section to provide information that a disabled user can act on - for example, avoid a particular section of the website, or request an alternative version rather than waste time trying to make it work with their assistive technology. Try to list in order of most impact to least impact.]
We know some parts of this website are not fully accessible:
- some text in data tables overlaps when zoomed in to higher font sizes
- PDF documents may not be fully accessible to screen reader software
- embedded videos may not have captions
- the way that some data is stored means that your device may not be able to recognise the language of some of the text
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 [email address]
- call [phone number]
- [add any other contact details]
We’ll consider your request and get back to you in [number] 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: [provide both details of how to report these issues to your organisation, and contact details for the unit or person responsible for dealing with these reports].
Technical information about this website’s accessibility
[Note: this form of wording is legally required in the UK, check your local legislation for information about what you need to include here]
[Name of organisation] 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
[Note: say that the website is fully compliant if the website meets WCAG 2.1 AA standard in full. Say that it’s partially compliant if it meets most requirements of the WCAG 2.1 AA standard. If it does not meet most requirements of the WCAG 2.1 AA standard, say that it’s not compliant.
If your website is either partially compliant or not compliant WCAG 2.1 AA standard, you’ll need to explain why. This will be due to one or both of the following:
- non-compliances - this means the content in question is in scope of the regulations, but there’s an accessibility problem with it
- an exemption - this means the inaccessible content is out of scope of the regulations, or it’d be a disproportionate burden for you to make it accessible
There’s a legally required way of expressing the compliance status of your website, so do not change it. The 3 options are as follows:]
- This website is fully compliant with the Web Content Accessibility Guidelines version 2.1 AA standard.
- This website is partially compliant with the Web Content Accessibility Guidelines version 2.1 AA standard, due to [insert one of the following: ‘the non-compliances’, ‘the exemptions’ or ‘the non-compliances and exemptions’] listed below.
- This website is not compliant with the Web Content Accessibility Guidelines version 2.1 AA standard. The [insert one of the following: ‘non-compliances’, ‘exemptions’ or ‘non-compliances and exemptions’] are listed below.
[Note: delete the options that do not apply.]
Koha is compliant with the Disability Discrimination Act and meets web site accessibility to the W3C AA standard. Koha has a JavaScript dialect compliant with ECMAScript 262 edition 5.1. It is compliant with W3C AA, compliant with PECR 2011 and the ICO’s requirement in regard to cookies. It uses CSS 1/2 Style Sheets in preference to HTML formatting.
Koha is compliant with the new public sector requirements which came in on 23rd September 2020 (https://www.gov.uk/guidance/make-your-website-or-app-accessible-and-publish-an-accessibility-statement) which require public-facing applications to be accessible to level WCAG 2.1 AA standard. The Open Source Koha community QA process also includes accessibility as a pass/fail test when adding new code to the software.
The Web Content Accessibility Guidelines, also known as WCAG, version 2.1 builds on WCAG 2.0 (for which Koha was already compliant). There are 17 differences between WCAG 2.0 and WCAG 2.1 ranging from device orientation, to improved accuracy for Screen Readers. WCAG 2.1 addresses changes to the web, and how new technologies can be implemented, so all users have equal access. Koha to supports these.
Koha supports keyboard-only navigation.
Font size, text and background colours can be changed.
The Koha open source community has a role in the development team of Web Accessibility Advocate. This role is currently held by Matt Blenkinsop, a Software Developer, at PTFS Europe, the UK’s main Koha vendor.
Non-accessible content
[Note: if the website is fully compliant with the WCAG 2.1 AA standard, you can leave the ‘Non-accessible content’ section out.
Otherwise, do not change the ‘Non-accessible content’ heading or the ‘The content listed below is non-accessible for the following reasons’ sentence - they’re legally required.
Do not change the ‘Non-compliance with the accessibility regulations’, ‘Disproportionate burden’ and ‘Content that’s not within the scope of the accessibility regulations’ subheadings: they’re also legally required.
But if you need to list a lot of problems, you can break these subsections up with further subheadings - for example, ‘Navigation and accessing information’ or ‘Interactive tools and transactions’.]
The content listed below is non-accessible for the following reasons.
Non-compliance with the accessibility regulations
[Note: In this subsection, list:
- accessibility problems
- which of the WCAG 2.1 AA success criteria the problem fails on
- when you plan to fix the problem
Do not include any problems where you’re claiming disproportionate burden, or where the problem is outside the scope of the accessibility regulations (those should go in the subsections below).]
EG: 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 September 2024. When we publish new content we’ll make sure our use of images meets accessibility standards.
Disproportionate burden
[Note: in this subsection list accessibility problems you’re claiming would be a disproportionate burden to fix
Bear in mind that something which is a disproportionate burden now will not necessarily be a disproportionate burden forever. If the circumstances change, your ability to claim disproportionate burden may change too.]
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. We will make another assessment when the supplier contract is up for renewal, likely to be in [rough timing].
Content that’s not within the scope of the accessibility regulations
[Note: in this subsection list accessibility problems that fall outside 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.
Live video
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
[Note: publishing an accessibility roadmap is optional. It’s a good idea to publish one if you want to be specific about the order you’re planning to tackle accessibility issues, and there’s no space to do so in the accessibility statement itself.]
Our accessibility roadmap [add link to roadmap] shows how and when we plan to improve accessibility on this website.
Preparation of this accessibility statement
[Note: the wording about when the statement was prepared is legally required, so do not change it.]
This statement was prepared on [date when it was first published]. It was last reviewed on [date when it was last reviewed].
This website was last tested on [date]. The test was carried out by [add name of organisation that carried out test, or indicate that you did your own testing].
We used this approach to deciding on a sample of pages to test [add link to explanation of how you decided which pages to test].
[Note: you do not have to use this approach to sampling, but you should link to a full explanation of what you tested and how you chose it. If you get a third party auditor to test your website for you, they should include sampling details in test report - so you can just to link to that.]
You can read the full accessibility test report [add link to report].