COMMUNICATE
Accessibility statements, author guidelines and sharing best practice.
- Communicating with Everyone - Accessibility Statements
- Communicating during Procurement - VPATs
- Communicating with Readers - Metadata and DAISY Reports
- Communicating with Authors - Author Guidelines
- Communicating Internally Across the Press - Accessibility Policy
Communicating with Everyone - Accessibility Statements
UK, EU, and US legislation all require an accessibility statement to be published on the organisational website. See relevant legislation sections for details, templates, guidance, and examples.
An accessibility statement is different to an accessibility policy in that it is publicly available and aimed at communicating about the accessibility of your book files and website in as plain language as possible. The purpose of an accessibility statement is to communicate with all members of the public and with any legislative auditors, and it is completed at the whole press level (rather than for individual books).
The statement details compliance with standards, parts that are not yet accessible, and future plans for remedying that. It is also where you provide contact details, enabling individual accessibility requests. This allows readers to understand the accessibility of your content without having to check it themselves, building trust through the assurance that you are addressing these issues consistently over the long term.
Because of all these benefits, even if you are exempt from the legal requirement to put a statement in place, it is still recommended to have something that communicates the above publicly. You could follow the legal guidance for your country as a starting point.
Examples
ASPIRE
The ASPIRE list for publishers is a review and verification service for accessibility statements. They analyse public accessibility statements and give them a percentage score, a rank, and a rating (e.g. Gold).
ASPIRE - publisher review process
Communicating during Procurement - VPATs
A VPAT stands for Voluntary Product Accessibility Template, and they are free templates provided by the Information Technology Industry Council (ITI) that help you to audit and describe the accessibility of your content. A completed VPAT is referred to as an Accessibility Conformance Report (ACR).
There are different versions of the VPAT template available for the most widely used accessibility standards including those based on WCAG, EU legislation, 508 (which means US legislation) and an international template called INT. We recommend completing this INT template as it can be used in all areas. You can download the templates at this link:
Voluntary Product Accessibility Templates
A VPAT is useful in a lot of situations when communicating the accessibility of your content at the point of procurement, and can be used to refer to by yourself when completing other work. It is completed at the whole press level, rather than the individual book level. It makes it clear exactly what success criteria constitutes compliance, although it can take a little bit of extra work to determine what that success criteria means in practice and how to fully audit it across all your content.
They are not a legal requirement and are voluntary, however, you could be asked to produce them by libraries, especially in the US. Sometimes, requesting libraries will accept the public accessibility statement instead of a VPAT. Using them would enable librarians to assess the accessibility of publisher content in a standardised format, in comparison with other publishers who use the same template. You would produce the VPAT on request from libraries, but you could also decide to publish your VPAT online.
The VPAT specifies 5 conformance levels:
- Supports: The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
- Partially Supports: Some functionality of the product does not meet the criterion.
- Does Not Support: The majority of product functionality does not meet the criterion.
- Not Applicable: The criterion is not relevant to the product.
- Not Evaluated: The product has not been evaluated against the criterion. This can only be used in WCAG Level AAA criteria.
Our recommended workflow for working long term with VPATs is below:
1. Complete an initial VPAT that just describes your ebooks (called Electronic Docs on the VPAT) as a whole and uses your existing knowledge of your workflows to complete it (not a full audit). This is part of our Getting Started advice.
2. Complete an audit of your ebooks and use this to complete a fuller VPAT, that ideally gets updated every year.
- Depending on the size of your catalogue, you might want to split this work in a meaningful way. The most obvious one might be to look at books published 2018 onwards, as most accessibility legislation does not apply before this date.
- Complete all of the success criterion that show 'Electronic Docs' on the VPAT (this will be a few more than those we recommend in the initial VPAT) up to level AA. For any that are Not Applicable, the ITI recommend that you actually assess this as Supports, stating, "if there is no content to which a success criterion applies, the success criterion is satisfied."
- Considering the 'remarks and explanations' column more fully might include providing:
-
-
-
Information regarding the testing of a given criteria.
-
Information on application dependencies to support accessibility (e.g. OS, app frameworks, browsers recommended).
-
How the customer can find more information about accessibility issues. One method can be to include the bug ID where customers can call the company’s customer support to get additional information.
-
Known workarounds for accessibility issues.
-
-
3. Audit the accessibility of your website (called Web on the VPAT) and you could consider producing a separate VPAT for this, although there would not be many situations where this would be used aside from your own reference.
ITI’s VPAT Training Modules and Additional Resources
VPAT® 101: Introduction to the Voluntary Product Accessibility Template (YouTube)
Examples
Liverpool University Press (Atypon)
Scholarly Publishing Collective
Communicating with Readers - Metadata and DAISY Reports
Metadata
We have summarised the most widely used metadata standards on our pages here: Standards - Metadata
DAISY reports
Ace SMART by DAISY is a recommended free open source tool that will generate an accessibility report for EPUBs. The output of these generates standardised text and lists accessibility features and conformance against standards, which can be copied onto book landing pages to give readers full information about your EPUBs in a standardised format.
There is a simple user guide available to get you started. To use the tool, you will need to have an idea of the accessibility of your EPUBs, which can be done automatically using Ace by DAISY, which is a separate auditing tool. In the output of this tool there will be a JSON file, that can be loaded into Ace SMART to generate a report. There are three steps after this has been loaded, Pub Info, Conformance and Metadata. There is a final Reporting tab after this where you can customise the reporting further. The user guide explains all of these steps.
Communicating with Authors - Author Guidelines
If not already, including accessibility requirements within author submission guidelines is recommended, and even if this is already something in place, then this guidance can help optimise the advice you give to authors. Authors are often the best people to handle many accessibility features, such as ALT text (especially for technical images), producing accessible charts and graphs, and structuring tables.
The following auditing checklist, from our manual checking guidance, has been modified and annotated with some specific requirements that authors can be asked to handle.
Text
- Do not include any images of text, but if this is absolutely essential, replicate the text in ALT text.
- All text colours have to have a contrast ratio of at least 4.5:1 to the background. You can check this with the WebAIM Contrast Checker.
- Headings must use the style tags within the authoring software you are using (such as Heading 1 etc), not just highlighted using larger or bold text. They must be describe the section they title well enough to use them alone to navigate the document. Just use a single Heading 1 per document, don't skip levels, for example, a Heading 4 underneath a Heading 2, and do not use Heading 7 or higher.
- If specifying fonts, they must be Unicode fonts.
- Headers, footers, notes, page numbers and references use the function within the authoring software you are using, not just with visual adjustments on the page, such as inserting line dividers manually.
Non-Text
- Provide a separate document giving ALT text for all figures/images and charts/graphs, referencing their title and your chosen ALT text. Please see this guidance for support writing ALT text:
- Colours used in figures/images and charts/graphs have to have a contrast ratio of at least 3:1. You can check this with the WebAIM Contrast Checker.
- Figures/images and charts/graphs have multiple ways of conveying meaning and do not just rely on one way, such as colour. Additional options include icons, symbols, shapes, patterns, dotted lines, or additional text.
- Links should have unique text that ensures users understand the purpose, context and relevance of the link, either from the link text alone (ideally), or from the immediate surrounding context of the link. Exceptions are PIDs such as URLs and DOIs in references, which are shown in full. Do not include the word 'link' anywhere in this.
- Do not use images of tables, but use the table function within the authoring software you are using.
- Other non-text content, such as mathematical equations, are tagged using an appropriate method (e.g. LaTeX).
- Any decorative artefacts, such as borders, line dividers, or repeating decorative images are tagged as such. The process for doing this will depend on the authoring software you are using (e.g. Microsoft Word).
Navigation
- Check that the reading order through the document is correct, using the tools provided by the authoring software you are using. The reading order should not impact on meaning in any way, for example, make a decision as to whether a table is best moved through row by row or column by column to maximise understanding.
- Use consistent navigation elements, such as page numbers being the same on each page or a similar level of heading used for similar, repeating sections.
Metadata
- Provide effective titles and language choices (both the overall document, and if the language changes at any point within it) within the file metadata. You should be able to check and edit this in the authoring software you are using.
Examples:
Submission Accessibility Guidelines at JSTOR Publishers
Accessibility FAQ for Books at JSTOR Publishers
Communicating Internally Across the Press - Accessibility Policy
Having a documented policy about how you want the organisation to handle accessibility might be a useful tool. If your press has more individuals involved, uses external partners more often or doesn't yet have a strong organisational buy in for accessibility, then it might be helpful to set expectations in a formal policy. It is not common for small diamond publishers to have one. Even so, an accessibility policy can help all stakeholders to understand exactly how they support accessibility with their work, and why they should be doing this. An accessibility policy is not the same as an accessibility statement, and is more of an internal document (while statements are public), but it can be shared alongside the statement, or include a lot of the same text.
Some recommended things to include in an accessibility policy are:
- A statement on the organisation's commitment to accessibility.
- The scope of the policy, to include book files, web pages and submission platforms.
- A statement that accessibility work is completed by all individuals involved in the organisation and is everybody's role. You could include the named person with overall responsibility for accessibility as well.
- The legal minimum standards you are working with, and a statement that all book files and the website will have a plan in place to achieve this standard.
- Your approach to achieving this work, for example, by working closely with authors, procuring third party systems or using the services of external partners.
- Details of where you are not in control of the accessibility of content i.e. third party providers.
- How everyone at the organisation will be trained in accessibility.
- How often you plan to do auditing work to benchmark improvements and progress along the roadmap.
- Time and budget investments that are planning to be made.
- How accessibility will be evidenced and checked.
- How the accessibility statement, and any other systematic documentation, will be created and kept up to date.
- Contact details for feedback and additional accessibility requests.
More information:
W3C Developing Organizational Policies on Web Accessibility
Accessible.org - How to Write an Accessibility Policy
Gov.UK Sample accessible documents policy
Examples:
Oxford Brookes University Accessibility Policy
University of Reading Digital Accessibility Policy