09. Open Accessibility

• 01 Principles of Open Accessibility
• The Principles
• 02 Accessibility Legislation
• UK
• EU
• US
• 03 Accessibility Standards
• Digital Content Standards
• Digital Document Standards
• Metadata Standards that include accessibility tags
• Markup languages that allow provision of accessibility features and tools
• 04 Strategic Planning for Accessibility
• Models, Frameworks and Charters
• The Open Accessibility Strategic Planning Model '10 Steps to Creating Custom Accessibility Roadmaps'
• A Preparation
• 01 Accountability
• Certification
• 02 Training
• 03 Identify Objectives
• B Analysis and Auditing
• 04 Baseline Auditing
• Automated Testing
• Manual Checking
• Assistive Technology Tests
• End user testing from print disabled people
• 05 Available and Required Capacity and Budget
• 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
• D Improvements and Benchmarking
• 09 Improvements
• 10 Benchmark Auditing
• 05 Example Work from other Publishers
• Accessibility Statements
• Author Guidelines
• Other
• 06 The Open Book Futures Accessibility Tools

01 Principles of Open Accessibility

The Principles

1. Access has not been fully provided to a research output unless it is Accessible.

2. Accessible means the research output is perceivable, operable, understandable and robust.

3. Scholarly communications professionals should seek to remove all barriers to access, including paywalls, accessibility barriers and others.

4. Research outputs should be Born Accessible by default, rather than accessible on demand or requiring a separate version that is available at a later time or through a different channel. 

5. No accessibility standard can capture the accessibility needs profile of an individual; therefore, individual accessibility requests must be responded to.

6. Accessibility enables usability and is not just for the print disabled but is for everyone to customise their reading experience.

7. Accessibility enables machine readability and is not just for humans but for robustness/compatibility with all automated systems.

8. Accessibility helps a research output to reach its true audience, not just those who can perceive/operate/understand it, or access it.

9. Disabled people have economic disadvantages that Open Access initiatives focused on removing paywalls can help with.

10. Open Access has advantages in accessibility that closed access does not, in particular through the absence of DRM technology interfering with assistive technology, the prior consideration of copyright restrictions that might prevent producing accessible versions, and other lack of restrictions on re-use enabling maximised usability.

02 Accessibility Legislation

UK

Relevant Acts

Equality Act 2010 is the legislation that states both public and private bodies cannot discriminate against those with a disability. It’s more rigorous for the public sector and there are increased reporting requirements. It doesn’t mention digital accessibility specifically but its broad application includes physical and digital services and resources.

The Public Sector Bodies Accessibility Regulations 2018 (PSBAR) is the legislation that applies to websites and mobile applications, and it only applies to parts of the public sector. Which types of digital content and which organisations within the public sector this act applies to is defined within the legislation, although it is complicated to understand, but there is some simplified guidance here: PSBAR Scope

To be compliant there are 2 components:

• meet the Web Content Accessibility Guidelines (WCAG) 2.2 AA accessibility standard

• publish an accessibility statement that explains how accessible your website or mobile app is

Intepretation of whether these acts apply to small diamond open access publishers

We would recommend that PSBAR applies to the eBook files (open and closed) and the website (both the public facing and any backend submission processes) of public sector publishers.

Most diamond OA publishers can be considered public sector, especially if the publisher is part of a public body i.e. a university, but also if the publisher has received public funding to start up, or if any content has received public funding at any part of its creation, for example, it has received public money to fund the research, or the publication of the monograph. Where this is unclear it would be advisable to consider the legislation as applicable anyway to avoid problems. 

If a small publisher is ever very clearly part of the private sector, then it is covered by the Equality Act which makes discrimination towards those with a disability (and other protected characteristics) illegal. This legislation is less specific as to the standards that apply and companies are not audited for compliance, however, providing inaccessible eBooks could be considered discrimination, and, it is never good for business to exclude large numbers of customers or readership. 

This does not constitute legal advice.

More information about legislative requirements:

GOV.uk Equality Guidance - Equality Act 2010: guidance

GOV.uk Digital Accessibility Guidance - Understanding accessibility requirements for public sector bodies

Make Things Accessible - What are the Public Sector Bodies Accessibility Regulations?

Standards referenced in these acts and how they are audited

Web Content Accessibility Guidelines (WCAG) 2.2 AA

The Government publishes detailed information on Accessibility Monitoring: how we test. Your website might be randomly selected to be audited by the Government Digital Service, and if there are any issues, you have to fix these in 12 weeks. The legislation requires regular self-audits, but does not specify a particular frequency - annual can be seen as the default.

More information about auditing:

Government Digital Service 2021 Monitoring report

GOV.uk Accessibility monitoring of public sector websites and mobile apps 2020-2021

AbilityNet - How well have the public sector accessibility regulations been applied?

Accessibility Statements

An accessibility statement should be published on the organisational website. There is some minimal legal wording for the accessibility statement available on a template here: Accessibility Statement Template. This statement needs to be updated annually.

The template requires information about how accessible the website and eBooks are, including details of all known accessibility issues, contact details for use to report any further issues or request additional adjustments, and any exemptions that you are claiming. It also needs to include the enforcement procedure text provided, and this cannot be changed or modified.

It's likely that one accessibility statement would cover a whole publisher, but you could consider having a separate statement for each distinct part of the organisation, for example, one for the website itself and one that just describes the eBook files. You should make the statement very easy to find from the homepage of your website. 

More information about accessibility statements:

Make Things Accessible - Accessibility Statements - what are they?

Make Things Accessible - How to write an accessibility statement

W3C Developing an Accessibility Statement

Examples of accessibility statements:

Open Book Publishers

Leuven University Press

Citizen's Advice

City of York Council

The Open University

Exemptions

The following organisations are exempt from the accessibility regulations:

• non-government organisations like charities - unless they are mostly financed by public funding, provide services that are essential to the public or aimed at disabled people

• public sector broadcasters and their subsidiaries

• primary and secondary schools or nurseries - except for the content people need in order to use their services, for example a form that lets you outline school meal preferences

There is no mention of micro-organisations in UK legislation.

PSBAR does not apply to the following content on websites and mobile applications:

• pre-recorded audio and video published before 23 September 2020

• live audio and video

• heritage collections like scanned manuscripts

• PDFs or other documents published before 23 September 2018 - unless users need them to use a service, for example a form that lets you request school meal preferences

• maps - but you’ll need to provide essential information in an accessible format like an address

• third party content that’s under someone else’s control if you did not pay for it or develop it yourself - for example, social media ‘like’ buttons

• content on intranets or extranets published before 23 September 2019 (unless you make a major revision after that date)

• archived websites if they’re not needed for services your organisation provides and they are not updated

There is also an exemption if accessibility would impose a disproportionate burden, but you’re legally required to carry out an assessment. 

More information about exemptions:

Make Things Accessible - PSBAR Exemptions

How to evidence disproportionate burden

Disproportionate burden is a clause within the accessibility regulations that provides exemptions based on the size and cost of remediation work relative to the organisation. The disproportionate burden clause is appropriate for smaller organisations, and could apply to many small diamond open access publishers.

You may only be able to evidence disproportionate burden for some accessibility aspects and not others. If you are thinking about making a disproportionate burden claim, it must be for something specific that cannot be accomplished, not general inability to consider improving accessibility at all or problems with testing the current accessibility of outputs. You will still need to respond to individual accessibility requests even if you are exempt due to disproportionate burden.

Organisations are legally required to carry out an assessment of the extent to which compliance with the accessibility regulations imposes a disproportionate burden. You cannot claim disproportionate burden without having completed and documented an assessment first. In essence you are not exempt until the assessment is completed.

Disproportionate Burden Assessments

Overall, a disproportionate burden assessment is balancing the burden that making those things accessible places on your organisation versus the benefits of making those things accessible.

You should describe:

• your organisation’s size and resources
• the nature of your organisation (for example, do you have services aimed at people who are likely to have a disability?)
• current accessibility issues and how you audited those
• how long an organisation expects this disproportionate burden to apply (for example, if an update or procurement is about to be completed)
• if the site or service is procured or outsourced, how long the third party supplier is contracted for, and how much it would cost to re-tender or renegotiate the contract to get the issues fixed

You should analyse:

• how much it will cost to fix the issues
• the amount allocated to spend on the digital products annually
• how these extra costs would impact the organisation’s budget
• the people or capacity needed to resolve the issue
• the benefits that fixing issues would bring to users
• how often the product is used or how long people spend interacting with it
• the number of users the issue impacts if not fixed

You should also:

• summarise the disproportionate burden assessment in your accessibility statement
• publish your evidence and test outcomes

What Makes a ‘Good’ Disproportionate Burden Assessment?

Some ways of evidencing disproportionate burden are to be avoided. In the 2021 report linked below, GDS specifically stated, “Lack of time or knowledge does not constitute a disproportionate burden.”

According to the 2020-2021 accessibility monitoring of public sector websites review, common issues with assessments include:

• organisations copying the disproportionate burden claim directly from the sample accessibility statement
• organisations claiming disproportionate burden without having carried out an assessment beforehand
• misunderstanding of when the disproportionate burden exemption applies, as opposed to other exemptions from the accessibility regulations

Within the AllAble research linked below, there are some further descriptions of bad practices encountered after requesting to see assessments:

• organisations saying they do not hold this information or no assessment was conducted (disproportionate burden cannot be claimed until this is completed)
• organisations saying they are in the process of conducting the assessment (disproportionate burden cannot be claimed until this is completed)
• organisations stating they originally claimed it but then changed their minds and forgot to take it out
• evidence provided that is dated after the request to see it was made
• organisations stating that the claim was discussed in meetings or calls and that there are no records of the decision

Many of these approaches highlighted as bad practice seem reasonable, but it is not enough within the legislation to consider it to be 'obvious' that accessibility issues have remained unfixed due to disproportionate burden. Even when very obviously out of reach for an organisation it must be assessed and evidenced, and if it really is that obvious then it should not be too difficult to demonstrate.

More information about disproportionate burden:

GOV.uk Digital Accessibility Guidance - When complying with accessibility regulations might be a ‘disproportionate burden’

DfE Accessibility and Inclusive Design Manual - disproportionate burden

2020-2021 PSBAR Monitoring Review

Make Things Accessible - understanding disproportionate burden

Make Things Accessible – how to write a disproportionate burden assessment

All Able 2020 Disproportionate burden misuse research

George Rhodes - an in depth article on disproportionate burden

Examples of disproportionate burden assessments:

GOV.uk Sample accessibility statement (for a fictional public sector website)

Equality and Human Rights Commission

Manchester City Council

University of Bradford

Cardiff and Vale University Health Board

Copyright Legislation

Copyright in the UK is covered by the Copyright, Designs and Patents Act. Exceptions to copyright are required under international legislation covered by the Marrakesh Treaty for print disabled/visually impaired people. This international law does not cover other impairments, such as dyslexia, but the UK’s Intellectual Property Office guidance does, as long as the person has lawful access to the original work and there are no commercially available accessible versions. 

EU

Relevant Acts

The European Accessibility Act (EAA) is the legislation that states some products and services need to be accessible to those with disabilities. It includes a wide range of devices and online based digital products and services including e-readers, computers, smartphones, payment terminals, websites and access to audio-visual media. It includes all economic providers/economic operators which includes both the public and private sector. It is based on the UN Convention on the Rights of Persons with Disabilities and was passed in 2019, and comes into force on 28 June 2025. The EAA does not specify a technical standard and leaves compliance details down to member states. It is often advised to presume WCAG AA compliance plus a published accessibility statement is the default.

There is also a separate EU Web Accessibility Directive, which applies to public sector websites and apps (and downloadable/embedded documents on them), and is applicable in all countries in Europe and in the European Economic Area. This is applicable to organisations selling to the public sector as well, but just includes online experiences, rather than digital hardware as in the EAA.

The directive requires:

• an accessibility statement for each website and mobile app;

• a feedback mechanism so that users can flag accessibility problems or request access to inaccessible content;

• regular monitoring of public sector websites and apps by Member States and reporting on the results.

The European standard for accessibility requirements for ICT products and services is called EN 301 549. Complying with this standard is a way for public sector bodies to meet the mandatory technical requirements of the current Web Accessibility Directive. New requirements in future versions of EN 301 549 or WCAG will not automatically become legally relevant to the Web Accessibility Directive. This will only be the case if these new requirements are included in Annex A of a new harmonised version of EN 301 549. It is expected that new versions of Annex A will align with Web Content Accessibility Guidelines (WCAG) 2.2 AA.

The EU Web Accessibility Directive was transposed into national law in all EU member states; you can check the full list of national transposition measures.

The Academic Network of European Disability Experts (ANED) maintains a searchable database on disability-related national laws, policies, strategies and initiatives in EU Member States, candidate countries and other associated countries. Accessibility is one of eight topics monitored. The data is compiled by ANED’s independent country experts, under the guidance of the network’s Scientific Director, and updated periodically.

The W3C Web Accessibility Initiative (WAI) maintains an international list of laws and policies in different countries.

Intepretation of whether these acts apply to small diamond open access publishers

European Accessibility Act

Seeing as the EAA applies to both the public and private sector as long as they are economic operators (as in, an organisation providing products and services, one that needs money to run) then yes EAA applies to diamond open access publishers, but only if there are more than 10 employees AND an annual turnover of more than EUR 2 million. Anything else the legislation refers to as a 'micro-enterprise' making them automatically exempt, which many small publishers will be classed as.

If these organisational limits are exceeded, then the EAA specifically references eBooks, "In the context of e-books, the concept of a service provider could include publishers and other economic operators involved in their distribution." This is not the clearest description of applicability, and it includes the word 'could', and given this it would be advisable to consider the legislation as applicable anyway to avoid problems (but only if you're not classed as a micro-enterprise). 

EU Web Accessibility Directive

The Web Accessibility Directive defines the public sector as:

• State, regional, and local authorities
• Bodies governed by public law and financed via public contract (there is a full definition of this in point (4) of Article 2(1) of Directive 2014/24/EU)
• Associations formed by those above, if those associations are established for the specific purpose of meeting needs of general interest, and do not have an industrial or commercial character

Therefore, the Web Accessibility Directive applies if the publisher is part of a public body i.e. a university, but probably also if the publisher has received public funding to start up, or if any content has received public funding at any part of its creation, for example, it has received public money to fund the research, or the publication of the monograph. Where this is unclear, again it would be advisable to consider the legislation as applicable anyway to avoid problems. The legislation covers websites, and embedded or downloadable files from them.

This does not constitute legal advice.

More information about legislative requirements:

AbilityNet - European Accessibility Act

Digital Accessibility Centre - The European Accessibility Act: Understanding Digital Accessibility

Web Accessibility Directive: Frequently Asked Questions

European Commission - Web Accessibility

European Disability Forum - Web Accessibility Directive

Standards referenced in these acts and how they are audited

The current EAA requirements align with Web Content Accessibility Guidelines (WCAG) 2.1 AA, but the new updated version that comes into force in 2025 is widely interpreted as aligning with Web Content Accessibility Guidelines (WCAG) 2.2 AA. Individual member states may have further specified technical standards.

EN 301 549 Annex A is the standard required to be compliant with EU Web Accessibility Directive, and it is roughly similar to WCAG 2.1 AA. Annex A also includes additional requirements that are not part of WCAG 2.1. Therefore, demonstrating that a website meets all the success criteria of WCAG 2.1 is not sufficient to provide a presumption of conformity with the Web Accessibility Directive.

National authorities will be responsible for carrying out regular monitoring, including reviewing complaints and following up on any reported non-compliance. The European Commission set out a methodology for monitoring for the Web Accessibility Directive which specifies either:

1. an in-depth monitoring method to verify compliance, in accordance with the requirements listed in point 1.2 
2. a simplified monitoring method to detect non-compliance, in accordance with the requirements listed in point 1.3

The monitoring methodology also describes how to carry out the sampling of websites and mobile applications, and describes what Member States must provide in their monitoring reports, including:

• the detailed description of how the monitoring was conducted;
• a mapping, in the form a correlation table, demonstrating how the applied monitoring methods relate to the requirements in the standards and technical specifications in the directive, including also any significant changes in the methods;
• the outcome of the monitoring of each monitoring period, including measurement data;
• a description of the mechanisms set up by Member States to consulting with relevant stakeholders on the accessibility of websites and mobile applications;
• procedures to make public any developments in accessibility policy relating to websites and mobile applications;
• information on training and awareness-raising activities.

More information about auditing:

European Commission - A monitoring methodology and the arrangements for reporting by Member States

W3C Web Accessibility Laws & Policies by Country

Web Accessibility Directive - Member States Published Monitoring reports 2022-2024 

Member States' bodies in charge of monitoring the Web Accessibility Directive

Accessibility Statements

The Web Accessibility Directive requires public sector bodies to provide and regularly update a ‘detailed, comprehensive and clear’ accessibility statement on their website or mobile application.

The accessibility statement must include the following information:

• The compliance status of the website or app;
• A list of the content (or functions) that is not accessible, including the content/function for which the disproportionate burden clause is being invoked and the content that is not within the scope of the Web Accessibility Directive;
• The date of the accessibility statement and when it was last reviewed;
• The method used to prepare the accessibility statement;
• A description of, and a link to, the feedback mechanism to be used to notify the public sector body of any accessibility issues or to request access to inaccessible content;
• The contact information of the relevant entity or person (as appropriate) responsible for accessibility and for processing requests sent through the feedback mechanism;
• A description of, and a link to, the enforcement procedure to be used in the case of unsatisfactory responses to any notification or request sent through the feedback mechanism;
• The contact information of the relevant enforcement body.

The accessibility statement can also include optional content, for example:

• An explanation of the public sector body's commitment to digital accessibility;
• Formal endorsement (at administrative or political level) of the accessibility statement;
• The date of the publication of the website and/or the mobile application;
• The date of the last update of the website and/or mobile application following a substantial revision of its content;
• A link to an evaluation report, if available, and in particular if the compliance status of the website or mobile application is indicated as being ‘fully compliant’;
• Additional phone assistance for persons with disabilities, and assistive technology users support;
• Any other content deemed appropriate.

The declarations made in the accessibility statement should be accurate and based on one of the following:

• an actual evaluation of the website's or mobile application's compliance with the requirements of the Directive, such as a self-assessment done by the public sector body or an assessment carried out by a third party, for example a certification;
• any other measures, as deemed appropriate by the Member States, which provide equal assurance that the declarations made in the statement are accurate.

The statement should indicate the method used.

There is a model accessibility statement in European Commission - A monitoring methodology and the arrangements for reporting by Member States. It provides more detail on mandatory and optional content requirements.

More information about accessibility statements:

W3C Developing an Accessibility Statement

Examples of accessibility statements:

Leuven University Press

European Commission

ENCA Network

Competition and Consumer Protection Commission

Agence Française de Développement

Exemptions

European Accessibility Act

Microenterprises with less than 10 employees and an annual turnover less than EUR 2 million or an annual balance sheet total less than EUR 2 million are exempt from the EAA accessibility requirements for services. They are also exempted from the requirement to document their assessment.

The EAA does not apply to the following content on websites and mobile applications:

• pre-recorded time-based media published before 23 September 2018

• office file formats published before June 28, 2025

• online maps and mapping services, if essential information is provided in an accessible digital manner for maps intended for navigational use

• third-party content that is neither funded, developed by, or under the control of the organisation using the content

• archived content that is not updated or edited after June 28, 2025

EU Web Accessibility Directive

Exemptions relating to the scope:

• Websites and mobile applications of public service broadcasters and their subsidiaries, and of other bodies or their subsidiaries fulfilling a public service broadcasting remit. However, these websites and mobile applications are covered by the European Accessibility Act.
• Websites and mobile applications of non-governmental organisations (NGOs) that do not provide services that are essential to the public. There is no specific definition provided for ‘services that are essential to the public’ in the directive, only the following example ‘such as services that are not directly mandated by State, regional or local authorities’.
• Websites and mobile applications of NGOs that do not provide services that specifically address the needs of, or are meant for, persons with disabilities.
• Member States may also exclude websites and mobile applications of schools, kindergartens or nurseries, except for the content relating to essential online administrative functions.

Exemptions regarding specific types of content:

• Office file formats included in web pages: these are documents such as PDFs, Microsoft Office documents or their open source equivalents. Documents published before 23 September 2018 are excluded unless they are needed for active administrative processes relating to the tasks performed by the public sector body concerned.
• Pre-recorded time-based media published before 23 September 2020.
• Live time-based media. If such media is re-published later or kept on the website, then it will be considered pre-recorded time-based media and this should be made accessible after a period of time, usually after 14 days. The directive states that when it is ‘impossible to procure the relevant services in due time’, the 14-day period might exceptionally be extended to ‘the shortest time necessary to make the content accessible’. The directive also states that priority should be given to ‘essential information’ relating to the health, welfare and safety of the public.
• Online maps and mapping services intended for navigational use (for example a map to find a public building) as long as essential information is provided in an accessible digital manner, such as postal address and nearby public transport stops. This should be provided in a form that is simple and readable for most users;
• Third-party content that is 'neither funded nor developed by, nor under the control of the public sector body concerned'. The directive states that such content should not be used if it hinders or decreases the functionality of the public service offered on the website (or mobile application) concerned. Where the purpose of content of websites or mobile applications of public sector bodies is to hold consultations or to organise forum discussions, that content cannot be considered as third-party content and should therefore be accessible, except in the case of user-contributed content which is not under the control of the public sector body concerned;
• Reproductions of items in heritage collections that cannot be made fully accessible for one of the following reasons: the incompatibility of accessibility requirements with the preservation of the item concerned or the authenticity of the reproduction, or the unavailability of automated and cost-efficient solutions that would easily extract the text of manuscripts (or other items in heritage collections) and transform it into content compatible with the accessibility requirements;
• Content of extranets and intranets published before 23 September 2019, until such websites undergo a ‘substantial revision’;
• Content of websites and mobile applications qualifying as 'archives', meaning that they only contain content that is neither needed for active administrative processes, or wasn't updated or edited after 23 September 2019.

The Web Accessibility Directive also states that delivering accessibility requirements should not impose a ‘disproportionate burden’ on public sector bodies.

More information about exemptions:

International Publishers Association - The European Accessibility Act for non-EU members

How to evidence disproportionate burden

The disproportionate burden clause appeara within both the European Accessibility Act and the EU Web Accessibility Directive, and it is designed to balance accessibility with the practical limitations of some organisations where the cost of compliance may be too high. National authorities set requirements around the reporting and reviewing of assessments, and applying penalties for non compliance.

Disproportionate Burden Assessments

European Accessibility Act

Annex VI states specific analyses that must be completed as part of any disproportionate burden assessment.

1. Ratio of the net costs of compliance with accessibility requirements to the overall costs (operating and capital expenditures) of manufacturing, distributing or importing the product or providing the service for the economic operators.
2. The estimated costs and benefits for the economic operators, including production processes and investments, in relation to the estimated benefit for persons with disabilities, taking into account the amount and frequency of use of the specific product or service.
3. Ratio of the net costs of compliance with accessibility requirements to the net turnover of the economic operator.

EU Web Accessibility Directive

This legislation requires similar information in disproportionate burden assessments.

1. The organisation's size, resources and nature;
2. The estimated costs and benefits for the organisation in relation to the estimated benefits for persons with disabilities, taking into account the frequency and duration of use of the specific website.

What Makes a ‘Good’ Disproportionate Burden Assessment?

According to the Web Accessibility Directive, measures that would impose a disproportionate burden should be understood as measures that would impose an ‘excessive organisational or financial burden’ on a public sector body, or would ‘jeopardise the body's capacity to either fulfil its purpose or to publish information needed for or relevant to its tasks and services, while taking into account the likely resulting benefit or detriment for citizens, in particular persons with disabilities’.

The Web Accessibility Directive states that ‘lack of priority, time or knowledge’, and that not procuring or developing accessible software systems, are both not legitimate reasons for claiming disproportionate burden.

If public sector bodies make use of the ‘disproportionate burden’ clause, they have to explain in the accessibility statement which parts of the accessibility requirements could not be complied with and provide accessible alternatives.

More information about disproportionate burden:

accessible.org Disproportionate Burden Exception under The EAA

Web Accessibility Directive: Frequently Asked Questions

Examples of disproportionate burden claims:

https://www.interreg-central.eu/jems-accessibility-statement/

https://www.eesc.europa.eu/en/accessibility-statement

Copyright Legislation

Copyright in the EU is covered by separate legislation in each country; these are broadly in alignment, although not completely the same everywhere. The European Commission provides an overview and some guidance. Exceptions to copyright are required under international legislation covered by the Marrakesh Treaty for print disabled/visually impaired people. This international law does not cover other impairments, such as dyslexia, but may be captured in individual European member’s state’s legislation.

US

Relevant Acts

The Americans with Disabilities Act (ADA) is the legislation that states both ‘state and local government entities’ (Title II) and private/business entities that are open to the public (Title III) cannot discriminate against those with a disability. Title II states that disabled individuals must be able to access and use web content through compliance with WCAG 2.1 AA.

Section508 within the Rehabilitation Act is the legislation that applies to all electronic and information technology from federal agencies. To be compliant you have to meet the Web Content Accessibility Guidelines (WCAG) 2.0 AA accessibility standard, and this will be updated to require the Web Content Accessibility Guidelines (WCAG) 2.1 AA standard from 24th April 2026. 

The Office of Management and Budget (OMB) memorandum on “Strengthening Digital Accessibility and the Management of Section 508 of the Rehabilitation Act“ (M-24-08) requires federal agencies to maintain an accessibility statement on their websites. 

The Nelson Memo also states that peer reviewed scholarly content should be available in such a format so that it is, “...enabling broad accessibility through assistive devices.”

Intepretation of whether these acts apply to small diamond open access publishers

Title II applies to all services, programs, and activities provided or made available by public entities, which are defined as: (A) any State or local government; (B) any department, agency, special purpose district, or other instrumentality of a State or States or local government; and (C) the National Railroad Passenger Corporation, and any commuter authority (as defined in section 24102(4) of title 49). Title II also specifically includes a section on web and mobile accessibility, which applies to all 'web content'.

Most diamond OA publishers can be considered public entities, especially if the publisher is part of a public body i.e. a university, but also if the publisher has received public funding to start up, or if any content has received public funding at any part of its creation, for example, it has received public money to fund the research, or the publication of the monograph. Where this is unclear it would be advisable to consider the legislation as applicable anyway to avoid problems. Section508 similarly applies only to federal agencies.

Title III applies to all private entities offering services to the public, which all open content can be considered to be, and alongside the Nelson Memo means that accessibility needs to be considered in general (both Title III and the Nelson Memo do not specify a digital accessibility standard).

More information about legislative requirements:

ADA.gov

ADA National Network - What is the Americans with Disabilities Act (ADA)?

ADA.gov Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local Governments

Section508.gov

Standards referenced in these acts and how they are audited

Web Content Accessibility Guidelines (WCAG) 2.0 AA

Web Content Accessibility Guidelines (WCAG) 2.1 AA

Agencies subject to Section 508 are required to report on the implementation of Section 508 to the Office of Management and Budget (OMB) and the General Services Administration (GSA) through the Annual Section 508 Assessment. A primary point of contact will be appointed, and this person will receive details of access to an online assessment reporting tool.

More information about auditing:

Section508.gov Government-wide Section 508 Assessment

Accessibility Statements

An accessibility statement should be published on the organisational website, which needs to include the following:

1. The accessibility standard applied to the website and any known limitations or alternative versions, as appropriate.
2. The contact information for the Section 508 program manager (name and email address).
3. A public feedback mechanism that allows members of the public to report accessibility problems with agency websites and digital services to the agency’s Section 508 program as well as relevant implementation teams.
4. Instructions for filing a complaint alleging a violation of Section 508.
5. Information about the agency’s reasonable accommodations procedures for Federal employees and job applicants, consistent with Section 501 of the Rehabilitation Act.
6. Instructions on the use of the telecommunications relay service.
7. Links to any relevant, publicly available organizational policies or procedures on digital accessibility.
8. Date that the digital accessibility statement was last updated or reviewed.

The statement should be linked to from the footer at the bottom of every web page. 

More information about accessibility statements:

Section508.gov Developing a Website Accessibility Statement

W3C Developing an Accessibility Statement

Examples of accessibility statements:

General Services Administration (GSA) Accessibility Statement

U.S. Nuclear Regulatory Commission (NRC) Accessibility Statement

US Department of Commerce

Exemptions

ADA and Title III

This legislation does not apply to private clubs or to religious organisations or entities controlled by religious organisations, including places of worship or schools.

Title II Web and Mobile Accessibility

The requirements do not apply to the following:

• Archived web content
• Preexisting conventional electronic documents, unless such documents are currently used to apply for, gain access to, or participate in the public entity’s services, programs, or activities.
• Content posted by a third party, unless the third party is posting due to contractual, licensing, or other arrangements with the public entity.
• Individualised, password-protected or otherwise secured conventional electronic documents. 
• Preexisting social media posts. 

Section 508

The requirements do not apply to the following

• Legacy ICT: Agencies may claim a ”Safe Harbor” for existing ICT that was accessible and compliant with the earlier standard on or before January 18, 2018 and has not been subsequently changed to affect interoperability, the user interface, or access to information or data. 
• National Security Systems: This exception applies to ICT operated by agencies as part of a national security system.
• Federal Contracts: This exception applies to ICT acquired by a contractor incidental to a contract. This exception does not apply, if: The ICT will revert to government ownership; The government directly procures the ICT; or Members of the public or government employees use the ICT.

• Functions Located in Maintenance or Monitoring Spaces: This exception applies to ICT functions located in spaces that are frequented only by service personnel for maintenance, repair, or occasional equipment monitoring. 

• Undue Burden or Fundamental Alteration: Conformance to the Revised 508 Standards is required only when it does not impose an undue burden, or result in a fundamental alteration in the nature of the ICT. 
• Best Meets: For when no ICT is commercially available that fully conforms to the Revised 508 Standards.

There is no mention of micro-organisations in US legislation.

More information about exemptions:

accessible.org Web Content Exceptions Under New Title II Rule

Section 508.gov Determine ICT Exceptions

How to evidence undue burden

The undue burden exception applies only to the specific features or functions of the ICT that cannot be made to conform without imposing an undue burden on the agency or component. The federal agency or component that owns (or will own) the ICT product or service must:

• Decide that conformance to the Standards would impose an undue burden;
• Assess costs relative to resources if claiming the exception based on expense; and
• Assess the difficulties in achieving conformance to claim the exception based on difficulty.

If the answer to all questions is ”yes”, your ICT may warrant this exception.

1. Have you determined that conformance for some or all features and functions of the ICT item would result in an undue burden on your agency or component?
2. Have you quantified the resources available to the program or component for which the ICT is to be procured, developed, maintained, or used?
3. Has the responsible agency official documented in writing how the difficulty or expense is significant, relative to the resources available? For example:
   1. What % of the expense equals total budget available?
   2. Explain exactly what is significantly difficult, and why.
4. Does your documentation address whether the exception is being claimed for the entire ICT Item, or only specific features and functions?
5. Will the agency provide an alternative means for users with disabilities for the features and functions for which you are claiming this exception?

Undue Burden Assessments

What Makes a ‘Good’ Undue Burden Assessment?

More information about undue burden:

Section 508.gov Determine ICT Exceptions

convergeaccessibility.com How to Comply with DOJ’s Seemingly Impossible Web Accessibility Regulation

Examples of undue burden claims:

Copyright Legislation

Copyright in the US is covered by chapters 1 through 8 and 10 through 12 of Title 17 of the United States Code. Exceptions to copyright are required under international legislation covered by the Marrakesh Treaty for print disabled/visually impaired people. This international law does not cover other impairments, such as dyslexia, but the US’s Section 121 (Chafee Amendment) does. This permits ‘authorised entities’ to make accessible copies for ‘eligible persons’.

03 Accessibility Standards

Digital Content Standards

Web Content Accessibility Guidelines (WCAG)

Web Content Accessibility Guidelines (WCAG) standards are the most commonly used standards that are mandated in many countries’ legal requirements. They are all based on 4 design principles: 

1. Perceivable - you have to be able to perceive all available content with senses the end user possesses

2. Operable - you have to be able to use all available content with different interfaces the end user can use

3. Understandable - you have to be able to understand all available content and how to access it with the ability the end user has

4. Robust - you have to be able to use the content in an interoperable and compatible way with third party technologies the end user can use

WCAG has different versions that appear in various legislations across the world.

• The UK requires 2.2, which was released in October 2023

• The EU requires a standard similar to 2.1 (called EN 301 549 Annex A). WCAG 2.1 was released in June 2018

• The US requires 2.0, which was released in December 2008. WCAG 2.0 is identical to ISO/IEC 40500:2012

Generally each version includes everything from the previous one, and adds extra, making them all backwards compatible. Between 2.0 and 2.1 there were 17 additions, and between 2.1 and 2.2 there were 9 additions, and 1 removal (this is Parsing, which has become obsolete). Therefore you could interpret this as the newer version therefore being stricter, higher standards.

The WCAG guidelines are split into 3 levels that increase in strictness, A, AA and AAA, with A being basic or minimum accessibility with 25 success criteria, AA strong with an additional 13 criteria (38 total) and AAA outstanding with an additional 23 criteria (61 total). AA is the default level that is captured in legislative requirements, and reaching WCAG A will not make a digital resource legally compliant. Some aspects of AAA are not applicable in many situations.

The WCAG standards are split into 13 guidelines, that are further split into more detailed success criteria - the number of success criteria depends on the WCAG level.

More information on the success criteria is available here: 

Web Content Accessibility Guidelines - Quick Reference

Web Content Accessibility Guidelines in Plain English

The full details of each version of WCAG are available here:

Web Content Accessibility Guidelines (WCAG) 2.2 AA

Web Content Accessibility Guidelines (WCAG) 2.1 AA

Web Content Accessibility Guidelines (WCAG) 2.0 AA 

EN 301 549 Annex A

EN 301 549 Annex A is the standard required to be compliant with EU legislation, and it is roughly similar to WCAG 2.1 AA. It has a broader scope than WCAG (which just covers websites), and includes all ICT products and services in the public sector, including specific requirements around web sites and documents that are both part of the website (HTML or embedded) or downloadable from them (called Non-web Documents). 

It includes the same 4 design principles of Perceivable, Operable, Understandable and Robust, and the requirements are mapped to WCAG and directly reference them. This includes the requirements around Non-web Documents, which are described separately to the requirements for Websites.

WAI-ARIA

Web Accessibility Initiative - Accessible Rich Internet Applications (WAI-ARIA) provides an ontology of roles, states, and properties that define accessible user interface elements and can be used to improve the accessibility and interoperability of web content and applications. Accessibility of web content requires semantic information about widgets, structures, and behaviours, in order to allow assistive technologies to convey appropriate information to persons with disabilities. These semantics are designed to allow an author to properly convey user interface behaviours and structural information to assistive technologies in document-level markup.

WAI-ARIA provides Web authors with the following:

• Roles to describe the type of widget presented, such as “menu”, “treeitem”, “slider”, and “progressbar”

• Roles to describe the structure of the Web page, such as headings, and regions

• Properties to describe the state widgets are in, such as “checked” for a check box, or “readonly” for most form controls

• Properties to define live regions of a page that are likely to get updates (such as stock quotes)

• A way to provide keyboard navigation for the Web objects and events, such as those mentioned above

CrossRef recommend tagging DOIs with an ARIA label, more information here: Accessibility for Crossref DOI Links

Digital Document Standards

Accessible EPUBs

EPUB Accessibility 1.1 addresses two key needs in the EPUB® ecosystem:

• evaluation and certification of accessible EPUB Publications;

• discovery of the accessible qualities of EPUB Publications.

This specification sets formal requirements to meet to certify content as accessible, and provides Authors a clear set of guidelines to evaluate their content against, and allow certification of quality. It is designed to be applicable to EPUB Publications that conform to any version or profile, including future versions of the standard.

An EPUB Publication must meet the following criteria to be accessible per this specification:

• It must meet the requirements for Discoverable EPUB Publications, including providing metadata on accessibility.

• It must meet the requirements for [WCAG 2.0] conformance defined in WCAG Conformance Requirements. This specifies WCAG 2.0 A as mandatory, and AA as recommended.

• It must meet the requirements for EPUB Publications defined in EPUB Requirements. This section covers providing navigation to static page break locations and synchronised text and audio playback.

It must include accessibility conformance metadata as defined in Conformance Reporting. This includes stating which WCAG level (A, AA, AAA) it conforms to, and who provided this certification. 

PDF/UA - ISO 14289-1:2014 and ISO 32000-1:2008

ISO 14289-1 is also known as PDF/UA (Portable Document Format, Universal Accessibility), and is aimed at everyone involved in creating PDF. It is based on the PDF standard ISO 32000-1 (also known as Adobe PDF 1.7) and directly references that. It sets minimum requirements that make sure documents are compliant with devices that support people with disabilities. PDF/UA files require the information on their pages to be tagged, and it also allows users to create structure trees out of tags so that assistive programmes know in which order to read information.

The Matterhorn Protocol is a guide on compliance with PDF/UA: https://pdfa.org/resource/the-matterhorn-protocol/

DAISY - Digital Accessible Information System

Digital Accessible Information System (DAISY), also known as ANSI/NISO Z39.86-2005 (R2012), is a digital talking book standard which offers a flexible and navigable reading experience for people who are blind or print disabled, offering a significantly enhanced reading experience—one that is much closer to that of the sighted reader using a print book. A Digital Talking Book (DTB) is a collection of electronic files arranged to present information to the target population via alternative media, namely, human or synthetic speech, refreshable Braille, or visual display, e.g., large print. DAISY multimedia can be a book, magazine, newspaper, journal, computerised text, or a synchronised presentation of text and audio. It provides up to six embedded "navigation levels" for content, including embedded objects such as images, graphics, and MathML. In the DAISY standard, navigation is enabled within a sequential and hierarchical structure consisting of (marked-up) text synchronised with audio.

Metadata Standards that include accessibility tags

There are two ways that metadata accompanies a publication. In the first are digital publication formats that directly embed accessibility metadata (EPUB and PDF). In the second are external metadata record formats (ONIX and MARC) that accompany a digital publication as it moves through the supply chain. In some cases, a digital publication may include both internal and external metadata (e.g., an EPUB could have accessibility metadata in it package document and also be provided to a vendor with an ONIX record).

Source: https://w3c.github.io/publ-a11y/a11y-meta-display-guide/2.0/draft/guidelines/

EPUB

EPUB publications MUST include the following accessibility metadata:

• accessMode — a human sensory perceptual system or cognitive faculty necessary to process or perceive the content (e.g., textual, visual, auditory, tactile).

• accessibilityFeature — features and adaptations that contribute to the overall accessibility of the content (e.g., alternative text, extended descriptions, captions).

• accessibilityHazard — any potential hazards that the content presents (e.g., flashing, motion simulation, sound).

EPUB publications SHOULD include the following [schema-org] accessibility metadata:

• accessibilitySummary — a human-readable summary of the accessibility that complements, but does not duplicate, the other discoverability metadata. The summary also describes any known deficiencies (e.g., lack of extended descriptions, specific hazards).

• accessModeSufficient — a set of one or more access modes sufficient to consume the content without significant loss of information. An EPUB publication can have more than one set of sufficient access modes for its consumption depending on the types of content it includes (i.e., unlike access modes, this property takes into account any alternatives for content that is not broadly accessible, such as the inclusion of transcripts for audio content).

EPUB creators MAY include additional [schema-org] accessibility metadata not specified in this section.

There is some companion guidance on Fixed Layout EPUBs and some guidance on techniques for extracting information from EPUB Accessibility Metadata

PDF

The PDF/UA standard (see below) defines how to describe accessibility metadata. There is also some companion guidance on creating a Well Tagged PDF

MARC

MAchine-Readable Cataloging (MARC) standards are a set of digital formats for the description of items catalogued by libraries, such as books. MARC 21 was designed to redefine the original MARC record format for the 21st century and to make it more accessible to the international community. MARC 21 has formats for the following five types of data: Bibliographic Format, Authority Format, Holdings Format, Community Format, and Classification Data Format.

Within the Bibliographic Format, there are specific fields to include accessibility metadata. 

ONIX 

ONIX is an XML-based standard for rich book metadata, providing a consistent way for publishers, retailers and their supply chain partners to communicate a wide range of information about their products. An ONIX record is a separate XML file that is sometimes packaged together with an ebook, and sometimes left separate, but either way, it is distributed alongside an ebook. It contains all kinds of metadata about a book, like title, author, edition, page count, etc. and a set of accessibility metadata.

Most ONIX Accessibility metadata is carried in the data element. This uses ONIX codelist 196 to specify particular accessibility options that are provided by the product. and Codelist 196 in ONIX provides for granular description of particular accessibility features of the e-book, and can also specify the e-book’s conformance with particular accessibility standards and provide links to further detail. ONIX does not describe reading system functionality. As well as , and and the relevant codes from List 81 are important to highlight content types in the e-book (text, images, audio and the like) that require mitigations for potential inaccessibility.

There some guidance on techniques for extracting information from ONIX Accessibility Metadata for display.

Crosswalk between ONIX and MARC: https://w3c.github.io/publ-a11y/drafts/a11y-crosswalk-MARC/

BIBFRAME

Bibliographic Framework (BIBFRAME) was designed to replace the MARC standards, and to use linked data principles to make bibliographic data more useful both within and outside the library community. Bibframe includes the property Contentaccessibility 

Schema.org

Schema.org is an initiative launched in 2011 by operators of the world's largest search engines at the time to create and support a common set of schemas for structured data markup on web pages. It includes the CreativeWork type ‘Book’ and includes several standard accessibility tags, including: AccessibilityFeature, AccessibilitySummary and AccessibilityHazard, plus others.

There are no accessibility sections associated with the following metadata standards

• Dublin Core

• BibTex

• DataCite

• CrossRef

• KBART

• OPDS

Markup languages that allow provision of accessibility features and tools

HTML Living Standard

Hyper Text Markup Language is the ubiquitous web page Markup standard, with HTML Living Standard being the current version beyond HTML5 that is now constantly updated, although HTML5 is used interchangeably with this. It was originally developed as a language for semantically describing scientific documents. It can be used on web pages, documents and applications.

XML

Extensible Markup Language is a meta-syntax that can be extended with new custom tags and used across different platforms and devices. In web applications, XML is used to store or transport data, while HTML is used to format and display the same data.

CSS

Cascading Style Sheets is a style sheet language used for specifying the presentation and styling of a document written in a markup language. It is designed to enable the separation of content and presentation, including layout, colours, and fonts, which can improve content accessibility. Separation of formatting and content also makes it feasible to present the same markup page in different styles for different rendering methods, such as on-screen, in print, by voice (via speech-based browser or screen reader), and on Braille-based tactile devices. 

JavaScript

JavaScript is the scripting language used to programme the behaviour of web pages, while HTML defines the content and CSS the layout/styling. It is a step up from CSS, allowing complex web page functions such as dynamically updating content, control of multimedia, and animated images.

Document Type Definition

A Document Type Definition defines the structure and the legal elements and attributes of an XML document. An application can use a DTD to verify that XML data is valid.

PreTeXt

PreTeXt is a markup language that captures the structure of textbooks and research papers in the mathematical sciences. PreTeXt documents serve as a single source which can be easily converted to multiple other formats, current and future. The best of DocBook, LaTeX, and HTML. Before June 2017, PreTeXt was called “MathBook XML.”

MathML ISO/IEC 40314:2016

ISO/IEC 40314:2016 also known as MathML, MathML is a markup language for describing mathematical notation and capturing both its structure and content. The goal of MathML is to enable mathematics to be served, received, and processed on the World Wide Web, just as HTML has enabled this functionality for text.

LaTeX

LaTeX is a typesetting system which includes features designed for the production of technical and scientific documentation. It is widely used in academia for the communication and publication of scientific documents and technical note-taking in many fields, owing partially to its support for complex mathematical notation. LaTeX is available as free software.

The Difference Between MathML and LaTex

LaTeX is an input format. It is how we mathematicians write our articles, books, webpages, and anything else where mathematics is involved. (And often anything where mathematics isn't involved.) It is not designed to be read as-is. It is intended to be processed into a suitable output format and then read.

MathML is an output format. It is not designed to be written directly, but it is designed to be read. Of course, one needs a suitable renderer: a browser for the sighted and something like MathPlayer for those who want their mathematics read aloud, but then the same is true of any output format. 

It is possible, though not always straightforward, to convert LaTeX to MathML. The main difficulty is that most websites don't bother with this route. They convert the LaTeX mathematics to a graphic which is then displayed, with the original LaTeX as the alt text. Because of how it is produced, the LaTeX is usually very simple (no complicated macros), and so it may be possible to get by with reading the alt text.

So if you want to read mathematics, look for MathML. If you want to write mathematics, learn LaTeX (or another TeX variant).

Source: https://www.access2science.com/latex/StaceyLatexNote.html

MusicML

Music Markup Language (MML) is an attempt to mark music objects and events with an XML-based language. Marking such objects should enable managing music documents for various purposes, ranging from music theory and notation to practical performance. This project is not complete and a work in progress. The first draft of a possible DTD is available and a few examples are provided of music pieces marked with MML that result in well-formed as well as valid documents. The approach is modular. Many modules are still incomplete and need more research and attention.

TTML

Timed Text Markup Language provides a standard markup language for synchronising text with media, for example for captions and subtitles. It is widely supported, unifies the increasingly divergent set of existing caption formats, and offers more control over subtitles than simpler formats.

SVG

Scalable Vector Graphics is a language for describing two-dimensional graphics in markup on a web page. This can be advantageous for inclusive design because vector graphics can be easily resized, and scaled up or down to different resolutions without loss of quality. SVG can also be augmented with additional semantics that make them compatible with assistive technologies such as screen readers.

VoiceXML

Voice Extensible Markup Language is a markup language for structuring interactive voice response applications and specifying interactive media and voice dialogs between humans and computers. It is used for developing audio and voice response applications In order to make these applications accessible to users who are deaf or hard of hearing, the language provides a mechanism for including text alternatives to audio content. 

DocBook

DocBook is a markup language for publishing computing and other technical complex scientific documents including books. It allows you to convert one source format into multiple target formats.

DTBook

DTBook or DAISY XML is a markup language used in DAISY Digital Talking Books.

04 Strategic Planning for Accessibility

Models, Frameworks and Charters

AbilityNet Digital Accessibility Maturity Model (DAMM)

This functions as a 7 step management tool to help leverage all capacity at an organisation to map existing accessibility, devise roadmaps and check in on progress. This model has 5 “dimensions” that are seen as parts of an overall strategy: vision, leadership, processes, capability and procurement, and 5 levels of achievement in each. The free downloadable version of the model includes a list of suggested questions to ask when consulting with stakeholders. 

AbilityNet HE and FE Accessibility Maturity Model

The HE and FE maturity model enables you to judge the maturity of your whole organisation's digital accessibility. This again has 7 sections with sets of questions with levels of 'agreement' as a response, which are then automatically scored to give you an overall rating of Bronze Silver or Gold. This interactive resource helps you:

• Determine where you are in the Accessibility Maturity Spectrum
• Understand risks; build on benefits
• Identify support needs

W3C Accessibility Maturity Model (draft)

This describes 7 “dimensions” where accessibility applies including communications, ICT development lifecycles and the organisational culture, along with suggestions in each dimension of points (or organisational functions) where accessibility can be evidenced, as well as varying levels of achievement in each point. This practical and customisable guidance, with a structure for co-ordinating evidence, is the most helpful method of presenting information to busy, praxis based professionals.

Accessible Books Consortium Charter for Accessible Publishing

Our objective is to make our e-books accessible to all. With this objective in mind, we, the signatories to this Charter, hereby commit to:

1. stating our accessibility policy on our web-site, including adherence to this Charter;
2. nominating a senior manager who will be responsible for accessibility;
3. raising awareness among, and provide technical training for, relevant staff;
4. designating and publicising a point of contact in our organization to assist persons with print disabilities to access our publications;
5. testing our digital publications for accessibility, incorporating appropriate feature descriptions and metadata;
6. monitoring our progress in this area;
7. promoting the adoption of accessibility standards throughout the supply chain; and
8. supporting national and international collaboration with organisations representing persons with print disabilities so as to increase the availability of publications in accessible formats.

Contact us if you wish to become a signatory to the Charter for Accessible Publishing.

Publishing Accessibility Action Group Accessible Publishing Charter

Our objective is to make all content accessible and to embed accessible practices throughout the publishing ecosystem. Every aspect of the publishing industry is integral to our mission, and we encourage you to consider signing the PAAG Charter for Accessible Publishing to show your commitment to this objective. You can join either as a publisher or as a publishing ally. Join our impressive group of signatories and show your support for this important declaration.

With this in mind, we, the signatories to this charter, hereby commit to:

1. raising awareness among, and providing training for, relevant staff.
2. nominating a company “accessibility champion” who can bring together key stakeholders to discuss potential accessibility improvements and act as a liaison for all accessibility information.
3. publishing our accessibility policy on our website, including our commitment to this Charter.
4. designating and publicising a point of contact in our organisation to assist persons with disabilities to access alternate formats of our content.
5. partnering with national and international organisations that provide support for the availability of publications in accessible formats.
6. incorporating appropriate accessibility features within our digital publications and platforms, according to the Web Content Accessibility Guidelines and other appropriate accessibility standards.
7. advocating for accessibility standards and collaboration throughout the publishing supply chain from author to reader.
8. utilising the accessibility metadata opportunities available to aid with the discovery of accessible content.
9. testing and validating content to ensure it is usable by people with print disabilities. Ideally this would include testing by persons with lived experience.
10. monitoring our progress in this area and regularly assessing the accessibility of our digital publications and platforms.

If you wish to become a signatory to the Charter for Accessible Publishing, please complete this declaration. 

Even UP: A UK and Irish University Presses Commitment to Equity, Diversity and Inclusivity

UK and Irish university presses are committed to equity, diversity and inclusivity in our workplaces, in who we work with and in what we publish.  Recognising that different presses and parent institutions have their own EDI initiatives but eager to collaborate in order to amplify them, we undertake to:

1. Share best practice for EDI across presses.
2. Commit to using either the AUPresses survey tool to collect demographic data, or our own surveys of comparable quality, in order to assess and understand areas in which we can improve, benchmarking across presses where appropriate.
3. Create and share a programme of training and events, such as guest speakers, webinars, online symposia.
4. Promote and demonstrate transparency and equal opportunity in recruitment and career progression processes in university presses, including:
   • paid internships,
   • listing salaries/salary bands on all entry level roles and on all recruitment advertising, subject to commercial or confidentiality requirements,
   • inter-press career mentorship for colleagues from under-represented groups.
5. Work together to raise awareness of career opportunities in our presses with groups that are currently underrepresented in scholarly publishing.
6. Have a designated lead for equality, diversity and inclusivity in our organisations and have those leads meet regularly.

Assess Your Section 508 Program Maturity

For the US only, there is a framework available to assess your organisational maturity within Section508 legislative requirements. This assesses for 4 criteria levels: Ad Hoc, Planned, Resourced and Measured, and covers 5 domains: Acquisition, Agency technology life cycles, Testing and Validation, Complaint Management and Training. It also includes a basic and advanced checklist.

The Open Accessibility Strategic Planning Model '10 Steps to Creating Custom Accessibility Roadmaps'

Considering what your accessibility goals are, and forming a plan or roadmap to achieve them, is an important part of accessibility work. Our strategic planning model features 10 steps split into 4 sections to help you devise a plan that works for your small press. The model featuring the information on this page is available to download in spreadsheet format from: The Open Book Futures Accessibility Tools, but in addition to this, there is some extra guidance and resource links available here within Copim Compass.

A Preparation

1. Accountability: Appoint a person to co-ordinate accessibility, who could be a dedicated accessibility professional or someone who has a wider portfolio of work that includes accessibility too. However, it's also important to remember that some accessibility work will be completed by almost everyone at an organisation.

2. Training: Plan technical digital accessibility training and support the identified staff to develop skills. 

3. Identify Objectives: Once relevant staff have been identified and trained, some organisational accessibility objectives can be devised through requirements gathering exercises. Any organisation should aim to meet legal minimum requirements, but it's possible to be exempt from that (this requires work to evidence), and you may decide to go beyond in some areas if it fits with your organisational values. Also, your readership might already have made accessibility requests you haven't been able to meet yet, or you could survey your end users to capture this 'reader voice' in terms of accessibility requirements. Finally, it's possible there are some community or discipline specific considerations to include as well.

B Analysis and Auditing

4. Baseline Auditing: Audit the current accessibility of all aspects of the organisation, including the frontlist and backlist book files, the website functionality and the backend submission platform. You could complete this yourself using self auditing, or employ an external auditor. You could also look at assessing current organisational knowledge, attitudes towards and motivations for engaging with accessibility work.

5. Available and Required Capacity and Budget: Improving accessibility requires dedicated time and money, and a full consideration of where this can be diverted to accessibility goals will help with planning. It is likely that you will have some idea of how long book production tasks take, and how much extra work accessibility improvements will add to that, but it could be that you will need to understand more about the relative simplicity or complexity of individual accessibility requirements (like ALT text, or checking colour contrast).

C Implementation

6. Documentation: Capturing the results of identifying objectives, auditing, and analysing resources might happen across a range of documentation that could include: an accessibility policy, roadmaps, strategic plans, updated author guidelines, or other documentation.

7. Plan Work: We recommend that frontlist and backlist/remediation are considered separately, and separate plans for the website including the backend submission process. 

8. Public Statements: Publish accessibility statements and roadmaps on the organisation's website, and include VPATs and public policies if that is decided on.

D Improvements and Benchmarking

9. Improvements: Incorporate planned accessibility improvements into workflows and complete the plan.

10. Benchmark Auditing: Audit the accessibility and organisational knowledge at regular intervals within the plan to showcase improvements. 

More advice on creating accessibility roadmaps: 

UK Government Digital Service: https://www.gov.uk/service-manual/agile-delivery/developing-a-roadmap

US Section 508: https://www.section508.gov/manage/playbooks/technology-accessibility-playbook-intro/play03/

A Preparation

01 Accountability

Appoint a person to co-ordinate accessibility, who could be a dedicated accessibility professional or someone who has a wider portfolio of work that includes accessibility too. However, it's also important to remember that some accessibility work will be completed by almost everyone at an organisation.

It is possible to delegate responsibility to third party providers of remediation services through Certification or getting external professionals to complete some of the Frontlist, Backlist and Website work. 

Certification

• Benetech’s Global Certificated Accessible (GCA)

• Fondazione LIA's Ebook quality assurance

 

02 Training

Plan technical digital accessibility training and support the identified staff to develop skills. 

 

Introductory Guidelines and Courses

• Accessible Books Consortium’s Accessible Publishing Best Practice Guidelines for Publishers

• Accessible Books Consortium’s Course on Accessible Publishing Concepts

• Accessible Publishing Learning Network’s Introduction to Born-Accessible Ebook Production

• Books without barriers: a practical guide to inclusive publishing

• DAISY Accessible Publishing Knowledge Base

• DAISY’s Inclusive Publishing Initiative

• Publishing Accessibility Action Group

• Inclusive Publishing in Australia: An Introductory Guide

• The ASPIRE guide to accessible PDFs part 1: a user’s guide to negotiating PDFs

• The ASPIRE guide to accessible PDFs part 2: creating (or improving) PDFs

• The ASPIRE guide to accessible PDFs part 3: accessible PDFs in education – create, test, cry…

• EPUB 3.3 W3C Recommendation

• Accessible Publishing Knowledge Base EPUB

• Department for Education Accessibility and inclusive design manual Training

03 Identify Objectives

Once relevant staff have been identified and trained, some organisational accessibility objectives can be devised through requirements gathering exercises. Any organisation should aim to meet legal minimum requirements, but it's possible to be exempt from that (this requires work to evidence), and you may decide to go beyond in some areas if it fits with your organisational values. Also, your readership might already have made accessibility requests you haven't been able to meet yet, or you could survey your end users to capture this 'reader voice' in terms of accessibility requirements. Finally, it's possible there are some community or discipline specific considerations to include as well.

B Analysis and Auditing

04 Baseline Auditing

Audit the current accessibility of all aspects of the organisation, including the frontlist and backlist book files, the website functionality and the backend submission platform. You could complete this yourself using self auditing, or employ an external auditor. You could also look at assessing current organisational knowledge, attitudes towards and motivations for engaging with accessibility work.

Automated Testing

Manual Checking

Assistive Technology Tests

End user testing from print disabled people

 

 

Automated Testing

There are many proprietary and open source tools available to audit accessibility using automated testing. Below we have collated our top picks for open source tools, however many publishers may have budget to purchase a tool to do this, therefore, we have included links to other curated lists of accessibility tools from recommended sources. It's important to note that automated testing is only part of the process and can only take you so far, as many accessibility features require human assessment, for example, automated tools can check for the presence of ALT text, but can only guess at it's quality, for example length or matching the file name, and full quality checking will always need a human.

EPUBs

Ace by Daisy: https://daisy.org/activities/software/ace/

Smart by Daisy: https://smart.daisy.org/

PDFs

PAC (Pdf Accessibility Checker): https://pac.pdf-accessibility.org/en

HTML and Web Pages

Wave Browser extensions https://wave.webaim.org/extension/

Accessibility Checker: https://accessibilitychecker.org/

Curated Lists of Tools

https://www.w3.org/WAI/test-evaluate/tools/list/

https://accessibility-manual.dwp.gov.uk/tools-and-resources

https://github.com/ediblecode/accessibility-resources?tab=readme-ov-file#checkers

https://www.a11yproject.com/resources/#tools

Manual Checking

Checklist for manual checking

You can download this checklist, produced by us, in a spreadsheet format with additional richer information, including an indication of the complexity of each task, from here: The Open Book Futures Accessibility Tools

EPubs and PDFs

Text Features

1. Text is actual text; not images of text.
2. Colours of text has contrast ratio of at least 4.5:1
3. Headings are descriptive of the content they contain
4. Text is reflowable without problems
5. Text can be resized without problems
6. Line height and spacing, letter spacing and word spacing can all be changed without problems
7. Orientation can be changed without problems
8. Fonts are coded correctly

Non-Text Features

1. Non-text features (figures, graphics, captions, links, mathematical expressions) have meaningful ALT text
2. Colours of non-text features (figures, graphics) has contrast ratio of at least 3:1
3. Non-text features (figures, graphics, captions, links, mathematical expressions) have multiple ways of conveying meaning
4. Links are accessible and meaningful
5. Other clickable elements are 24 x 24 pixels
6. Other clickable elements have visible text that matches the text in the underlying code
7. A list's numbers, letters or bullets are displayed and tagged correctly
8. A tables's headers, rows and columns are tagged correctly

Semantic Tagging

1. Non-decorative/real and decorative/artefact content is all tagged correctly
2. Non-text features (figures, graphics, captions, links, mathematical expressions) are tagged and grouped correctly
3. Lists, tables and TOCs are tagged correctly
4. Headers, footers, notes and references are tagged correctly
5. Headings are tagged as headings
6. Headings have just 1 <H1>, at the beginning
7. Headings <H2>-<H6> don't skip levels
8. No headings <H7> or higher
9. Other non-PDF structure elements tagged correctly (Epubs)
10. PDF tags support the separate reading order (PDFs)
11. PDF role mapping is correct (PDFs)
12. Other structure elements in PDF tagged correctly (PDFs)

Reading Order and Navigation

1. Multiple ways to navigate
2. Static page breaks are present (Epubs)
3. Static page breaks are navigable (Epubs)
4. Navigation consistent throughout
5. Reading/focus order retains meaning when using tabs or a screenreader
6. Repeating blocks of content can be skipped

Metadata and Conformance reporting

1. File has metadata
2. File metadata has a title that is used instead of file name
3. File metadata has a valid language
4. Where the language changes, individual parts have a valid language
5. Source of static page breaks/pagination is identifiable (Epubs)
6. File metadata includes full accessibility conformance information

HTML and Web Pages

For HTML books and web pages, you would need to consider all of WCAG AA, rather than just the selected checklist above, which only includes aspects of standards that apply to ebook files that need to be manually checked. Below are a list of already available widely used full WCAG based checklists:

WebAIM's WCAG 2 Checklist

Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0

Deque Accessibility Developer's Guide

Please note that completing these checklists does not equal full certified compliance with WCAG AA.

Other checklists:

W3C Easy Checks

UK Government: Basic accessibility check

Web Content Accessibility Guidelines - Quick Reference

Web Content Accessibility Guidelines in Plain English

Assistive Technology Tests

We recommend running at least a sample of eBooks through assistive technology in order to double check that everything works OK, and best if this is a range of the most commonly used tools that fulfill a range of functions. The minimum checks you complete should be checking that:

• the file opens
• the file displays properly in a way that's understandable
• everything within the file can be used with that technology

There are different types of assistive technology that are commonly in use and you should check through at least one example of each type.

Contrast, Colour and Font Changers

Try different settings using:

• Windows High Contrast mode
• Different browser's settings, such as Firefox and Chrome
  

Screen Readers

NVDA desktop screen reader and JAWS desktop screen reader are commonly used open source applications that you can download and test with. It's also recommended to check using mobile screen readers such as VoiceOver on iOS or TalkBack on Android. Complete the following tests using these technologies:

• Read every element and header
• Tab through every link
• Check every landmark, for example your footer and any navigation
• Check your use of Accessible Rich Internet Applications (ARIA)
• Check you can fill in any editable fields, for example writing and submitting a form

Screen Magnifiers

Use desktop features such as Windows Magnifier or mobile features such as Apple Zoom to check this. Complete the following checks using these features:

• Test up to at least 4 times magnification
• The spacing between elements, for example the gap between a form label and field
• That page elements display consistently on different page layouts - so someone who is zoomed in to a page can always find the search box, for example
• That users know when something happens outside the viewport - for example, with modals or error messages

Speech Recognition

Dragon speech recognition is a commonly used proprietary desktop screen reader that you can test with. It's also recommended to check using mobile speech recognition on iOS or Android. Complete the following tests using these technologies:

• Navigate to each feature using speech
• Activate every link, button, or interactive element, for example form controls or a media player using speech
• Enter text into any forms if applicable to your service using speech, say punctuation out loud and correct any spelling mistakes you make

Make sure you speak clearly, but naturally. You should also use a high quality headset rather than an in-built microphone in your local machine and make sure you’re at a consistent distance from the microphone. 

WebAim articles on:

using JAWS to evaluate web accessibility
using NVDA to evaluate web accessibility
using VoiceOver to evaluate web accessibility

UK Government advice:

https://www.gov.uk/service-manual/technology/testing-with-assistive-technologies

End user testing from print disabled people

While not common for small presses, and likely this is beyond available capacity, best practice would be to approach end users with disabilities to test a sample of book files, web pages and submission systems. Below is some advice on finding user testing opportunities like this, if presses decide to go down this route.

The best feedback will always come from end users with disabilities, and from older users, as it can uncover accessibility barriers that are commonly experienced by your readership, yet are not captured within legal minimum accessibility requirements. 

In most cases, including users in evaluation involves:

• getting a few people with disabilities, and depending on your target audience, older users
• including them throughout the development process to complete sample tasks on draft book files and websites so you can see how different aspects of the design and coding could be improved before publication
• discussing accessibility issues with them

Advice taken from:

W3C Involving Users in Evaluating Web Accessibility

W3C Involving Users in Web Projects for Better, Easier Accessibility

The Gov.UK website includes a set of hypothetical user profiles to give you working examples of the range of users and their needs. These can be used to develop a strong idea of accessibility use cases and may help make content design decisions.

Understanding disabilities and impairments: user profiles

More information:

AbilityNet - A Step-by-Step Guide to User Testing

AbilityNet - Product and Services - User Accessibility Testing and Research

05 Available and Required Capacity and Budget

Improving accessibility requires dedicated time and money, and a full consideration of where this can be diverted to accessibility goals will help with planning. It is likely that you will have some idea of how long book production tasks take, and how much extra work accessibility improvements will add to that, but it could be that you will need to understand more about the relative simplicity or complexity of individual accessibility requirements (like ALT text, or checking colour contrast) before you can assess this.

See our checklist for tasks to consider during this process.

C Implementation

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.

Accessibility Policy

Author Guidelines

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

1. Do not include any images of text, but if this is absolutely essential, replicate the text in ALT text.
2. 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.
3. 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.
4. If specifying fonts, they must be Unicode fonts.
5. 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

1. 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:
   1. 1. • W3C Image Tips and Tricks
         • W3C ALT text decision tree
         • Alt-texts: The Ultimate Guide
2. 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.
3. 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. 
4. 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. 
   
5. Do not use images of tables, but use the table function within the authoring software you are using.
6. Other non-text content, such as mathematical equations, are tagged using an appropriate method (e.g. LaTeX).
7. 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

1. 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.
2. 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

1. 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

The Website functionality

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

VPATs

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.

UK Accessibility Statements

EU Accessibility Statements

US Accessibility Statements

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.

Voluntary Product Accessibility Templates

ITI’s VPAT Training Modules and Additional Resources

D Improvements and Benchmarking

09 Improvements

Incorporate planned accessibility improvements into workflows and complete the plan.

10 Benchmark Auditing

Audit the accessibility and organisational knowledge at regular intervals within the plan to showcase improvements.

05 Example Work from other Publishers

Accessibility Statements

https://www.openbookpublishers.com/libraries/accessibility

https://lup.be/accessibility/

https://www.sup.ac.uk/information-for-authors  

• Alternative Text for Illustrations Spreadsheet

https://www.whpress.co.uk/publications/terms-of-use/

https://uolpress.co.uk/accessibility/

https://uolpress.co.uk/information/for-authors/

 

Author Guidelines

Submission Accessibility Guidelines at JSTOR Publishers

Other

Accessibility FAQ for Books at JSTOR Publishers

06 The Open Book Futures Accessibility Tools