C Implementation
- 06 Documentation
- Accessibility Policy
- Author Guidelines
- 07 Plan Work
- Book files Frontlist / Born Accessible
- Book files Backlist / Remediation
- The Website functionality
- 08 Public Statements
- Accessibility Statements
- VPATs
06 Documentation
Capturing the results of identifying objectives, auditing, and analysing resources might happen across a range of internal documentation that could include: an accessibility policy, updated author guidelines, the roadmaps and strategic plans created in Section 4, or other documentation.
Strategic Planning - Models, Frameworks and Charters
10 Steps to Creating Custom Accessibility Roadmaps
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
BBC Digital Product Accessibility Policy
Harvard Business Publishing Digital Accessibility Policy
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 person 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.
07 Plan Work
We recommend that frontlist and backlist/remediation are considered separately, and that separate plans are also created for the website including the backend submission process.
Book files Frontlist / Born Accessible
Book files Backlist / Remediation
Book files Frontlist / Born Accessible
This type of work concerns making accessibility improvements to books that are about to be published. It will involve making changes to how your authors, typesetters and any external providers are required to work. The frequency with which you introduce improvements, and in what order you introduce them is up to yourselves. If you have a low volume of books you may approach this on a book by book basis, or for higher volumes you might want to 'version' improvements, for example, focus on all the easy wins for books being published in the next year.
If you are only able to consider some of the requirements in the checklist below, which encompasses the legal minimum, you will still need to plan to go back and remediate in the future so you can do all of them (see Book files Backlist / Remediation). Once these have been achieved, you may decide to go beyond this legal minimum in future frontlist 'versions', to introduce some of the requirements of WCAG AAA.
Taken from our checklist for manual checking of ebook files, here we have ordered tasks by level of complexity. You can see a full spreadsheet of this checklist, with details of the complexity level, suggested approaches to checking and improving, whether this can be machine automated and whether a publisher, author or both needs to be involved, here: (to follow)
Easy wins
Text is actual text; not images of text
Colours of text has contrast ratio of at least 4.5:1
Text is reflowable without problems
Text can be resized without problems
Line height and spacing, letter spacing and word spacing can all be changed without problems
Orientation can be changed without problems
Other clickable elements are 24 x 24 pixels
Other clickable elements have visible text that matches the text in the underlying code
A list's numbers, letters or bullets are displayed and tagged correctly
Non-decorative/real and decorative/artefact content is all tagged correctly
Non-text features (figures, graphics, captions, links, mathematical expressions) are tagged and grouped correctly
Lists, tables and TOCs are tagged correctly
Headers, footers, notes and references are tagged correctly
Headings are tagged as headings
Headings have just 1 <H1>, at the beginning
Headings <H2>-<H6> don't skip levels
No headings <H7> or higher
Other non-PDF structure elements tagged correctly
Multiple ways to navigate
Navigation consistent throughout
Repeating blocks of content can be skipped
Medium
Headings are descriptive of the content they contain
Fonts are coded correctly
Colours of non-text features (figures, graphics) has contrast ratio of at least 3:1
Links are accessible and meaningful
A tables's headers, rows and columns are tagged correctly
Static page breaks are present
Static page breaks are navigable
Reading/focus order retains meaning when using tabs or a screenreader
File has metadata
File metadata has a title that is used instead of file name
File metadata has a valid language
Source of static page breaks/pagination is identifiable
File metadata includes full accessibility conformance information
Complicated
Non-text features (figures, graphics, captions, links, mathematical expressions) have meaningful ALT text
Non-text features (figures, graphics, captions, links, mathematical expressions) have multiple ways of conveying meaning
PDF tags support the separate reading order
PDF role mapping is correct
Other structure elements in PDF tagged correctly
Variable
Where the language changes, individual parts have a valid language
Book files Backlist / Remediation
This type of work concerns making accessibility improvements to books that have already been published. It will involve making changes to your existing book files, which might require getting in touch with authors.
Most legislation specifies a date, before which documents are exempt from meeting minimum accessibility requirements. You could plan to work from this date forwards (if your press has existed for that long), and once that has been achieved make those before that date accessible too. The dates specified are as follows:
- UK: documents published before 23 September 2018
- EU: 'office' files published before 23 September 2018
- US: there is no specification for documents, but it does contain a 'Legacy ICT' exemption date of 18 January 2018, which also states this needed to be compliant at the time
You could also use usage and citation metrics to determine which titles to start with (i.e. the most accessed ones first), if your back catalogue is big enough, otherwise it might be enough to consider all of them together.
You might decide to outsource this work to external remediation providers. It's important to be able to have detailed technical discussions with these professionals about your requirements, to be able to ask for evidence these requirements have been completed, and to be able to check the quality of work they have completed for you.
Taken from our checklist for manual checking of ebook files, here we have ordered tasks by level of complexity, which might help you be able to complete this work, or outsource it effectively. You can see a full spreadsheet of this checklist, with details of the complexity level, suggested approaches to checking and improving, whether this can be machine automated and whether a publisher, author or both needs to be involved, here: (to follow)
Easy wins
Text is actual text; not images of text
Colours of text has contrast ratio of at least 4.5:1
Text is reflowable without problems
Text can be resized without problems
Line height and spacing, letter spacing and word spacing can all be changed without problems
Orientation can be changed without problems
Other clickable elements are 24 x 24 pixels
Other clickable elements have visible text that matches the text in the underlying code
A list's numbers, letters or bullets are displayed and tagged correctly
Non-decorative/real and decorative/artefact content is all tagged correctly
Non-text features (figures, graphics, captions, links, mathematical expressions) are tagged and grouped correctly
Lists, tables and TOCs are tagged correctly
Headers, footers, notes and references are tagged correctly
Headings are tagged as headings
Headings have just 1 <H1>, at the beginning
Headings <H2>-<H6> don't skip levels
No headings <H7> or higher
Other non-PDF structure elements tagged correctly
Multiple ways to navigate
Navigation consistent throughout
Repeating blocks of content can be skipped
Medium
Headings are descriptive of the content they contain
Fonts are coded correctly
Colours of non-text features (figures, graphics) has contrast ratio of at least 3:1
Links are accessible and meaningful
A tables's headers, rows and columns are tagged correctly
Static page breaks are present
Static page breaks are navigable
Reading/focus order retains meaning when using tabs or a screenreader
File has metadata
File metadata has a title that is used instead of file name
File metadata has a valid language
Source of static page breaks/pagination is identifiable
File metadata includes full accessibility conformance information
Complicated
Non-text features (figures, graphics, captions, links, mathematical expressions) have meaningful ALT text
Non-text features (figures, graphics, captions, links, mathematical expressions) have multiple ways of conveying meaning
PDF tags support the separate reading order
PDF role mapping is correct
Other structure elements in PDF tagged correctly
Variable
Where the language changes, individual parts have a valid language
The Website functionality
1. Front end for readers
Your public facing website is also included within accessibility legislation, which usually requires WCAG AA compliance. For websites, the whole of WCAG applies, rather than the specific ebook checklist we have produced, where only the aspects that apply to static ebook files are included. Websites also have interactive content, forms, and audio visual media, all which have specific accessibility requirements.
For institutional presses, this will likely be handled by your institution, and you will have a CMS in place that ensures the accessibility (and uniform institutional look and feel) of your website. For scholar led presses, this support will not be there, however, the service who is hosting your web page will also likely use a CMS that ensure accessibility. In all scenarios, it's important to be able to check this, see Baseline Auditing
2. Back end / submission for authors
Whether the submission platform is part of the same website or is on a different system, you will also need to check this for accessibility, using the same auditing advice and the same standards (all of WCAG AA) as above.
3. HTML Books
Publishers may make the decision to format eBooks as a HTML web page, which can provide a very accessible copy of the book. This again will require WCAG AA compliance, and while all of this will apply, for a HTML book there will less likely be interactive content, as it is designed to be another version of a static EPUB or PDF book file.
08 Public Statements
Publish accessibility statements and roadmaps on the organisation's website, and include VPATs and public policies if that is decided on.
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 is aimed at communicating to end users in as plain language as possible. The purpose of an accessibility statement is to communicate with the public, especially your end users or readership, about the accessibility of your book files and publisher web site. It is where you detail compliance with standards, parts that are not yet accessible, and the plans you have to remedy that. It is also where you give contact details to make individual accessibility requests. This lets readers know about the accessibility of your content without having to check it out themselves, and builds trust in them that you are handling these issues 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 available publicly. You could follow the legal guidance for your country as a starting point.
VPATs
The ITI Voluntary Product Accessibility Template (VPAT) is a free template that translates accessibility requirements and standards (e.g., in Section 508 and other legal frameworks) into actionable testing criteria for products and services. Users should test their products and services against each section of the VPAT and use the template to document results. Once completed, the VPAT with documented testing results is referred to as an Accessibility Conformance Report (ACR) that details the accessible features of the tested product or service.
The VPAT is offered free of charge. Membership in ITI is not required to use the VPAT. Please note, however, that the VPAT name and report form are ITI registered service marks, and should not be altered without the express written permission of ITI. There are different versions based on the leading accessibility standards: Section 508 (U.S.), EN 301 549 (EU), and W3C/WAI WCAG, which are available at the link below.
They are not widely used by publishers to describe their content, and they are not a legal requirement. 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. However, it is also not common for librarians to use these templates and to seek them out to make decisions.