the alt text specialists
ASPIREplatform guidelines
Every website is unique and tells a different story. There are common themes, however, and the guidelines below will help you craft an accessibility statement that is transparent and informative for your users.
The Template
Government Digital Services (GDS) have drafted a sample accessibility statement for public sector bodies. If your accessibility statement doesn’t contain this information, your customers are likely to be badgering you since they will need to provide it themselves. We strongly recommend you take this into account when constructing your own. It will be good for customer relations.
Alistair McNaught was part of a team contributing to this model approach and provides some highlights here for crafting an accessibility statement that is meaningful for your audience (and helps with your ASPIRE score).
​
In the sections below, we translate the GDS template into something relevant to a supplier context.
1. Be Discoverable
Ensure accessibility information is central and well signposted.
This seems an obvious point yet, in the ASPIRE project, where auditors were unable to find accessibility information, the suppliers scored zero. Where auditors could not find an appropriate link from the supplier homepage, they used Google to find accessibility statements. This did not not necessarily lead to the most up to date information. Some suppliers had a significant range in their score because different auditors had scored them on the basis of different URLs revealed by a Google search. Ensure accessibility information is central and well signposted. Identify and remove out of date information.
2. Using the resource (i.e. ‘things that work well’)
You cannot assume all users know how to make best use of an accessible file or interface. This section is a key marketing pitch to tell users what you’ve done for accessibility, what works and how they can benefit from it.
​
The content covered will vary depending on whether you are responsible for file formats, delivery interfaces or both. Where there are multiple file formats, you can provide guidance on the differences – for example changing background color in an ebook is easier on a PDF viewed in Adobe Reader than an EPUB viewed in Adobe Digital Editions. Where functionality is not specifically available (but your product is compatible with other tools), you might suggest free tools or plugins to make the difference – for example text to speech browser plugins, clipboard readers, color changing tools etc. We can support you with this guidance.
​
All the ASPIRE criteria where you have a positive answer should feature in this section. It will probably be your biggest section. It could include information on:
​
-
magnification and reflow,
-
personalization options such as color / contrast, line spacing, margins etc,
-
availability of image descriptions,
-
navigation options (e.g. tagging for headings and subheadings etc),
-
key-board only navigation/operation,
-
interoperability with assistive technology (this may be influenced by Digital Rights Management (DRM) decisions so clarify this where applicable).
3. How accessible is the product (i.e. ‘are there issues the user should know in advance?’)
How can you save people wasting time trying to do something that you know won’t work?
Inform users about any accessibility issues that have not yet been resolved – for example if images lack descriptions or PDFs are not tagged for reading order or screenreader testing failed on the interface. Letting people know in advance is better customer service than ignoring the issue, letting disabled users waste time finding the problem and then trying to resolve it too late. DRM restrictions can have an impact on the tools the end user can use so mention these where applicable. Examples include:
​
-
EPUBs being tied to Adobe Reader so losing much of their accessibility,
-
Copying restrictions reducing functionality for text to speech tools that rely on the reading the clipboard.
​​
By being transparent about what doesn’t work you can discuss other options available (see below) and help manage expectations. You may be able to suggest alternatives such as:
​
-
accessing the content a different way that has more closely matches the reader’s needs for example:
-
download a different format,
-
read it online,
-
read it in a Kindle edition on a phone or tablet.
-
​​
-
free tools or plugins to make the difference, for example color overlay tools or high contrast settings can compensate for a lack of color change options in a delivery interface. We can support you with this guidance.
​
UK law regards the base level accessibility requirement as meeting the requirements of the EU Accessibility requirements suitable for public procurement of ICT products and services in Europe – this is very closely aligned to Web Content Accessibility Guidelines 2.1 at AA level.
4. What to do if you need better accessibility than currently available (who to contact)
If the options above still don’t meet the needs of a disabled reader, they may need a more accessible option or a DRM free version that their local alternative format team can help with. This is the place to describe your ‘support ecosystem’. For example is there a dedicated email, phone number or internal role responsible for accessibility? Do you have your content distributed through RNIB Bookshare collection or the Access Text Network etc?
​
This information may already be in place, in which case you might simply add a link from the accessibility statement. This is a useful place for information on:
​
-
contact details,
-
response times,
-
licensing terms + conditions,
-
typical response times.
5. Embedding accessibility
This is designed to demonstrate both confidence and competence so it covers:
​
-
when the testing was done and this accessibility statement was updated (your customer’s accessibility statements are expected to be updated at least annually).
-
what the testing involved (which assistive technologies were used),
-
roadmap – this could include:
-
what the testing showed (probably covered in sections above) and whether it showed a need to make improvements. If it did, what’s the plan?
-
how internal workflows and quality assurance processes have incorporated accessibility.
-
This is not a one off exercise. You are expected to update the statement annually and reduce ‘disproportionate burden’ claims as your expertise and awareness improves.
ASPIREplatform review criteria
The ASPIREreview provides feedback on a range of criteria that should be covered in your accessibility statement. Below you will find details of the criteria and the type of information that should be included in your statement.
COMMUNICATION
​
Webpage Discoverability
Ensure that your accessibility statement is easily found on your website or through a search engine.
​
The publisher’s website should include easy to find accessibility information. This may be in the form of a dedicated accessibility help page, or it could be a section within the publisher’s standard help or support information. The important thing is that the information should be easy to find. If it can’t be found, your score is likely to be zero.
​
Information Currency
Make sure that accessibility information is up-to-date and state clearly when the page was last updated. Old information might actually undersell subsequent improvements.
​
Contact Details
The accessibility help page should include contact details, e.g. a telephone number, email address or web form, so users experiencing difficulties can request support or request a file in an accessible format. Allow your customers to easily ask questions.
​
Response Times
The accessibility information should indicate how long it will take to receive a response to an accessibility query or an accessible file request for a disabled learner. The response time stated should be reasonable, e.g. days rather than weeks, given that the user is likely to have a limited time-frame in which the title will be useful for their studies. Since these requests are vital to student study needs, response times should be based on likely time to fulfill the request, not the time it takes for an automated email-responder system to deliver a holding email.
​
Supplying an accessible file (or an unrestricted file which the library/disability team can make accessible) is usually the responsibility of the publisher but aggregators/platform providers may also get these requests and have their own arrangements for responding. It is very helpful to have an indicative response time in an accessibility statement.
Some requests ("please supply the raw PDF so we can add semantic headings ourselves") may be quicker to fulfill than others ("please supply a fully marked up version of this PDF"). Some requests are unreasonable ("Please provide this in Microsoft Word format"). The accessibility statement should provide a realistic assessment of the turnaround time for typical requests. It is reasonable that it might include caveats for more complex requests.
​
​
​
​
​
​
​
CONTENT INFORMATION
​
Digital Rights Management
Be clear about any usage restrictions you place on your content and outline your approach to supplying DRM-free copies to eligible readers.
​
The accessibility information should clearly state whether your files are protected by Digital Rights Management (DRM). If they are, the restrictions should be clearly explained in order to avoid users wasting their time with trial and error, e.g. “Files can only be opened using Adobe Digital Editions” or “It is not possible to copy text”,
​
Copying + Printing
Within an academic context, the ultimate purpose of reading an eBook is to use it for a curriculum related use. Users are likely to want to export text extracts or diagrams into their own notes or directly into assignments, and allowing copying supports this.
The accessibility information should state whether it is possible to copy text from the publisher’s files, and any limitations on this, e.g. “It is possible to copy up to 10% of each file”.
The ability to print from an eBook is a useful feature for people who prefer to process information in printed rather than electronic format.
The accessibility information should state whether it is possible to print from the publisher’s files, and any limitations on this, e.g. “It is possible to print up to 10% of each file”.
​
Formats
Be clear about which formats (such as EPUB or PDF) you make available in the market.
​
The accessibility information should state which format the publisher’s files are provided in, e.g. PDF, EPUB2, EPUB3. Guidance should also be given on using these formats. This should include any software required to open the files and a link to download it, along with information on how to modify accessibility settings (or links to this information on the software provider’s website). For example:
“To open PDF files, you will need a PDF viewer such as Adobe Reader. Please see the following guide for advice on using the inbuilt accessibility features of Adobe Reader:
Reading PDFs with reflow and accessibility features
​
​
Image Descriptions
The inclusion of image descriptions, especially for academic content, greatly increases the accessibility of your content. Be honest about how you are approaching image description and state clearly what the customer can expect from your content.
​
It is important for images and diagrams that convey information to have meaningful text descriptions in order to avoid excluding readers from key information. There are various ways this can be achieved, including adding a description to the alternative text HTML attribute (alt=) attached to the image, fully describing the image within the surrounding text or including a detailed description in the image caption. Decorative (i.e. purely aesthetic) images do not require a text description and should have a null attribute (alt=””) to save screen readers reading the image filename aloud.
The accessibility information should state whether images included in the publisher’s files have meaningful descriptions and provide detailed information about the form of these descriptions. If the publisher’s files do not include any images, this should also be stated in the accessibility information.
Aggregators are unlikely to be adding image descriptions. The important thing for them to clarify is whether their online platform ‘transmits’ any image descriptions supplied by publishers and, if so, in what way (Caption? Alt text? LongDesc? etc.).
Navigation
Outline the navigation tagging structure and reading order that you have implemented within your eBooks. Publishers put huge effort into developing accessible files - tell the story of your efforts.
​
The accessibility information should state whether the publisher’s files have been structured for accessibility so that they can be navigated by screen reading software, meaning they are accessible to blind and severely visually impaired users. The accessibility information should also specify whether platforms can be navigated by keyboard only (for non-mouse users) as well as which structural accessibility features the publisher’s files have. Structural accessibility features may include navigational tagging (e.g. heading levels, hyperlinks) or reading order. Dyslexic readers also benefit from well structured headings in files. Built in tools (e.g. Adobe Acrobat Reader’s ‘Bookmark’ panel) or browser plugins (e.g. HeadingsMap) lets readers quickly identify sections of interest.
​
Magnification + Reflow
The ability for users to alter the text to a size they can comfortably see is an important accessibility feature. Magnification is particularly useful for people with visual impairments, older people with declining eyesight and people with dyslexia, who may find small font sizes difficult to read.
The accessibility information should state whether the text size can be changed in the publisher’s files, and if so, instructions for doing so (or a link to external instructions) should be provided.
When text is magnified, it should automatically reflow, i.e. re-wrap to fit the page. If reflow does not work and the page is simply enlarged within a frame, the user has to scroll left and right to read the entire line, which presents a huge barrier to efficient access.
The accessibility information should state whether text in the publisher’s files will reflow when the zoom level is changed, and if so, instructions for activating the text reflow setting (or a link to external instructions) should be provided.
Reflow and magnification capability may vary with file format. Where multiple formats are on offer, guidance should be available on any format based accessibility differences.
​
Colors + Contrasts
The ability to change colors and contrasts is very important to many disabled readers. This includes some dyslexic readers find their comfort levels and reading efficiencies improve with certain color combinations. Changing color can also make reading more comfortable for people working in very bright (or very dim) ambient light.
The platform tends to exert the biggest control on how readily colors. Even if the platform itself does not allow color change, its accessibility statement might point to browser plug-ins or third-party tools and apps that would provide appropriate functionality.
​
Screen Reader Compatibility
Screen readers are assistive technologies for people with a high degree of visual impairment. These readers access the device, the software interface and the text content purely by listening to audio feedback audio and interacting via the keyboard or a touch screen device. Sample screen readers in a UK setting include JAWS, NVDA, VoiceOver (iOS) and SuperNova. Different screen readers are optimized for different browsers so look to see which screen reader/browser combination has been used for accessibility testing.
Although the quality of the publishers file has an impact on screen reader experience, biggest impact on screen reader success is the interface through which the file is viewed. For this reason, we only look at screen reader compatibility when auditing a platform. The file-specific accessibility features that benefit screen readers are covered by other questions in the publisher audit.
​
Text-to-Speech
Text-to-speech tools are used by readers who can see the screen and can use the mouse or keyboard controls to select the text that they want to listen to. Text-to-speech is important to dyslexic students who find it difficult to take the meaning from the written words in an efficient way. It benefits many others too, including people with no disabilities who want to give their eyes a rest or those who need to ‘read’ whilst doing other tasks like care responsibilities.
Text-to-speech tools come in many forms. Some are inbuilt to the platform interface (ReadSpeaker is one example). Some are stand-alone tools and some work as browser plug-ins. Many text-to-speech tools require selecting text and copying it to the clipboard where the text-to-speech kicks in. Digital Rights Management often prevents more than 10% of a book being read this way. This can be problematic for dyslexic students whose course requires them to read the other 90% as well.
Where clear guidance is given on text-to-speech functionality (or even limitations), it is easier for staff and students to anticipate problems and plan solutions.
