6.1. General Principles.
6.2. HTML and Epub.
6.3. Screenreader-Accessible Files (SAFs).
6.4. PDF format.
6.5. Email.
6.1. General Principles.
The following should be adhered to when producing electronic documents or digital publications in all formats, unless where otherwise specified, including html, Epub, .doc/.docx/.rtf, .pdf, and email.
6.1A. Legibility.
6.1B. Images.
6.1C. Language.
6.1D. Writing Styles.
6.1A. Legibility.
6.1A1.Tables Are Not For Text.
6.1A2. Numbering of Sections.
6.1A3. Fonts.
6.1A4. Formatting of Texts.
6.1A5. Single Page (Portrait) Layout.
6.1A1.Tables Are Not For Text.
Tables should only be used for the presentation of numeric data, not for the presentation of text. This is because screenreaders will, by default, announce each row and column of a table before reading out each box, seriously impacting the fluidity and intelligibility of the information to the listener. Also, tables were not designed for the linear reading of a screenreader.
Instead, for universal accessibility, we ask that the alternative of using clearly marked sections and subsections be used in all textual contexts (see next subsection, 6.1A2).
6.1A2. Numbering of Sections.
Unless where reproducing or referencing another document, Roman Numerals should not be used in numbering sections. All other numbering styles are accessible to screenreader users. However, where there are subsections, the full number should be given every time, e.g., in representation of statutes, of a Section 27, to subsequently include all relevant parts of the sequence, such as 27 (1) (a); 27 (1) (b); 27 (2) (a), etc. At least in part, his is because the indented formatting which is a useful wayfinding device for sighted people (including partially sighted people), is generally not detectable by screenreader users.
6.1A3. Fonts.
Please do not be adventurous with fonts. The standard, such as Times New Roman or Arial, are standards because they are clear. There is a lesser-used font, Abadi MT Condensed, which may be more beneficial to partially sighted readers since the narrowness of the font can increase reading speed; and if the Abadi MT Condensed font is intentionally not installed by the reader, the default is reverted to.
Normal font size of 16 pt is recommended to facilitate easier reading. We recommend this as the standard in original documents to make them more accessible by default to partially sighted readers. If the original uses larger font sizes for titles and headings, then this should also be replicated in the SAF document to facilitate those with partial sight. This will still not be large enough for many partially sighted readers, and therefore, all SAF documents should have full editing privileges when available or sent to the reader, not least so that a partially sighted reader can easily adjust the font size to suit their own particular needs.
6.1A4. Formatting of Texts.
Similarly, formatting of texts, such as different sized fonts, bold fonts, indentation, and changes in alignment (e.g., occasional centering), which are used to facilitate navigation for the fully-sighted reader, are also similarly useful for the accessibility of a document to a partially sighted reader, and so, should always be retained (including in Screenreader Accessible files, where possible.
While we acknowledge that colour-coding can be a very illustrative tool for some sighted readers, including some partially sighted readers, colour coding intrinsically puts screenreader users at a serious disadvantage, since such coding is, de facto, inaccessible. Colour-coding of texts can also mean that partially sighted readers find parts of the text difficult or impossible to read.
Where there is shared editing of a document and strikethrough is used, this strikethrough is by default, not accessible to screenreading technology, and so, such text reads like any other text to the screenreader-user, making such shared editing documents difficult or impossible to access.
Alternatives to such sight-based formatting of fonts is a matter of reasonable accommodation when dealing with an individual or small group of people, but in the case of general documents, universal design should mean that heading-based alternatives are used instead of visually-based effects. In terms of corrections of a document (e.g., in an educational setting), the preferences of the individual student are paramount, but the use of square brackets [] for corrections or editorial comments may be an idea worth exploring for accessibility of a screenreader user.
6.1A5. Single Page (Portrait) Layout.
Document creators and editors should be careful not to preserve or produce text in ‘book’ view, e.g., where a line from page 2 on the left is horizontally aligned with a line on page 3, on the right). Editors should be careful when copying over such text, since Optical Character Recognition can alternate between the lines of each page, presenting them one under the other in the one column, meaning that the text is a mishmash of both pages.
6.1B. Images.
6.1B1. General.
Where images are used in html, Epub, or .pdf, Images and texts should not rely on each other for intelligibility. It should be possible to read a text without having to look at an image in order to get all relevant information. Visual descriptions should therefore be integrated into the text. The alt text functions are generally inadequate, since they only have a character limit of 60 letters.
6.1B2. Maps.
Where maps are used, details such as dimensions, distances, and directions should be provided in the image description, as relevant, but with the information being provided as clearly and in as much detail as possible in the text itself.
6.1C. Languages.
6.1C1. Monolingual Documents Only.
6.1C2. Language Tagging.
6.1C1. Monolingual Documents Only.
Where possible, each document or stream of information should be monolingual – i.e., be in just one language, and not mixing languages. Even when they are separated within a document or stream,different languages can be very confusing for a screenreader user, and can also make a document more difficult to navigate. This does not include loan-words or institutional titles, e.g., Oireachtas, Dáil Éireann, Seanad Éireann, or Bus Éireann, etc., or loan words which are part of the original document.
Also, specific exceptional contexts include cultural and educational settings, where a second language is either being taught, or where a drama or artistic work retains original multilingual texts to preserve its integrity.
Generally speaking, accessible communications should be available at least in English and Irish, and both choices equally easily locatable (cf. Official Languages Act, 2004)..
6.1C2. Language Tagging.
Electronic documents (including on apps, websites, HTML 5, .rtf, .doc/.docx, .pdf, etc.), need to be appropriately tagged so that other languages are not pronounced by screenreading technology through English phonemes, e.g., Irish teach /tʃɑx/ (house) should not sound like English ‘teach’ /tiːtʃ/ (as in educate). The same need for proper language tagging applies to every language, especially remembering that document producers may be working from a default English tagging.
6.1D. Writing Styles.
6.1D1. Easty to Read (ETR) Format.
6.1D2. Technical Terms and Conceptual Complexities.
6.1D3. Acronyms.
6.1D1. Easy to Read (ETR) Documents.
Easy-to-read (ETR) documents – which facilitate reading by people with intellectual disabilities –are an obligation for public bodies under the CRPD (Article 9), and this is a given. ETR documents should conform to Section 5 of this document (VVIMAC) so that they can be accessed at the same point and time by blind and partially sighted people with intellectual disabilities as their fully sighted comparitors.
6.1D2. Technical Terms and Conceptual Complexities.
In all other documents, we ask, of course, that plain language be prioritised. However, for consistency, professionals use technical terms for internal and external communications, and this consistency is important for clarification. Where such technical terms are used, a glossary in documents and on the website of the public body should be present, or else an explanation at the first time of use.
Similarly, the public does not need talking down to. While nothing should ever be made more complicated than it is, and there is a lot to be said for the concept of ‘keep it simple’, where relevant nuance and complexities do exist, these need to be clearly explained.
6.1D3. Acronyms.
There is nothing wrong with acronyms once the full name is read out, with the acronym in parenthesis, at the first mentioning of the body or item concerned. It is easier for partially sighted readers, screenreader users, and braille-readers to read the acronym RTÉ every time the broadcaster is mentioned, rather than having to read Raidió Teilifís Éireann every single time; and similarly, the Department of Children, Equality, Disability, Integration, and Youth, once identified as DCEDIY on its first mention, is much quicker and easier to read via the DCEDIY acronym at all other times afterwards.
6.2. HTML and Epub.
The latest version of Epub format, or HTML format (currently HTML5) is generally accessible where the website accessibility standard of Section 5 of this manual has been met, and as such, is a good default format for documents, resources allowing.
6.3. Screenreader-Accessible Files (SAFs).
6.3A. Requirement that SAFs be Always Available.
6.3B. Zero Images or Logos in SAFs.
6.3C. Formatting Within the SAF.
6.3D. Pagination.
6.3E. Full Editing Permissions.
6.3F. Further Assistance.
6.3A. Requirement that SAFs be Always Available.
6.3A1.The Basics.
6.3A2. Advantages of SAF types Over other File Types.
6.3A1. The Basics.
File formats with the extensions .rtf, .doc and .docx (Screenreader Accessible File (SAF) types), are the basic staple of word processing in Windows, and can be easily accessed on other operating systems also, including Apple and Android.
Every Windows Operating System contains WordPad, which can read and edit theSAF types, and free programmes such as OpenOffice.org also facilitate reading and editing SAF types.
Where a document is begun/created in an SAF type on any operating system, it is generally, by default, mostly accessible to screenreading technology. Such accessibility can be improved on (see below)).
Because of the general default accessibility of SAF types, where a public body is attaching or otherwise offering downloadable documents, there must always be an easily available SAF version of the document. This is in addition to any other formats which may be the default, such as .pdf, .ppt, or xls etc.
Although documents begun as SAF types tend to be, by default, screenreader accessible, pasting other formats into SAF types may not work for screenreading technology, and if it is image-based, e.g., from an untagged .pdf or .jpg or .png, it is guaranteed to be 100% unreadable by screenreading technology.
6.3A2. Advantages of SAF types Over Other File Types.
- SAF types (.txt, .doc, .docx, .rtf( are more likely to be more accessible by default (without being dependent on proper tagging as with .pdf files, for example). By accessibility here, we mean that content and functionality must be readily available and usable by visually impaired readers (including screenreader-users).
- Unlike our non-screenreading comparitors, who can use their eyes to browse different reading programmes, screen-reader-users need to learn new keyboard commands for navigation for each different program they use, and if this can be avoided, it reduces the number of barriers to be overcome. Some of us have more skills, resources, and supports, to be able to overcome such barriers than others, but the needs of those with the least resources should be prioritised.
- For legacy and personal editing reasons, screenreader-users are already likely to have, and be familiar with, the commands of Word (or compatible programmes such as OpenOffice). Platforms such as Adobe Acrobat use other specific keyboard commands:
https://helpx.adobe.com/ie/acrobat/using/keyboard-shortcuts.html - screenreader users are more likely to be familiar with a wide range of editing possibilities when working with Word formats, so that they can customize a document to make it even more accessible according to their own personal preferences.
- for everyday editing, a screenreader-user is likely, already, to have editing software that works with SAF types (e.g., MS Word or OpenOffice, and so, does not need to depend on another programme, such as Adobe Acrobat Reader, which is also likely to cost more money if editing facilities are required.
- SAF-compatible programmes have better keyboard navigation options to those accessing .pdf files: e.g., bringing the focus to the beginning or end of a line, and to read or skip from paragraph to paragraph.
- Unlike .pdf files, SAF types has the advantage of being transformable into braille by Duxbury braille transcription software, which is currently the most used such software by braille transcription service providers in Ireland.
- forms and surveys in SAF .doc/.docx are fillable by many screenreader-users, which is not the case for them in .pdf or traditional paper form.
6.3B. Zero Images or Logos in SAFs.
Unless the SAFs are very small, all images need to be removed, since not only are images inaccessible to screenreading technology, but they also disproportionately inflate the size of a Word document, making such a document slow to download or impossible to open (using a screenreader.
As with 6.1B above, the same standards apply in terms of all useful and relevant information being contained in the text, as well as Useful descriptions of original images being provided in the appropriate places.
6.3C. Formatting Within the SAF.
The SAF formatting should be kept as simple as possible, including:
6.3C1. Headings and Paragraphs.
6.3C2. No Text Boxes.
6.3C3. Turn Off automatic Listing Functions.
6.3C4. High Contrast or Invert Colours Schemes.
6.3C1. Headings and Paragraphs.
Use of heading styles is advised for optimal screenreader accessibility by screenreader users. Where an individual prefers different paragraph heading styles, e.g., the option of paragraph marker “No Spacing”, this should also be respected as reasonable accommodation.
However, in all cases, not only should the original paragraphing be retained so that a screenreader-user can navigate by paragraph (using the keyboard), but where paragraphs are indented in the original document, for the possible facilitation of those with limited sight in navigating a document, including those who use screenreaders, such indentation should be maintained in the SAFs.
6.3C2. No Text Boxes.
Use of textboxes can cause unnecessary problems for screenreader users. This also means that framing an entire document in a box is problematic, since it can affect the focus of the screenreader. This is because text-boxes create a text area in a text area, and unless the text box is logically arranged by setting properties, a screenreader will either not get to read the text, or the text will not appear in a logical order to the screenreader.
6.3C3. Turn Off automatic Listing Functions.
Automatic list functions such as autonumbering or autobulleting can cause navigation difficulties for screenreader users, and so, should be disabled when creating SAFs. For example, the search/find function cannot be used to locate numbers when they are generated by autonumbering.
Use of the asterisk (manually typed), followed by a tab-key indent, produces a similar effect to bulleting, and section or subsection numbers should be manually typed, in order to be fully accessible to screenreading technology.
6.3C4. High Contrast or Invert Colours Schemes.
All text in all electronic documents should support the Windows High Contrast Scheme and equivalents such as Android and Apple’s respective Invert Colours Schemes. Where simple formatting is used, this compatibility should happen automatically.
6.3D. Pagination.
6.3D1. Single Page Layout Only.
6.3D2. Manually Write Page Numbers Before Relevant Text.
6.3D3. No Gaps.
6.3D1. Single Page Layout Only.
Too often, in SAFs, with double-page layout, the screenreader will read the same corresponding line on the next (right) page, rather than returning to the first word on the next line of the left page. Even if this does not happen, navigation within double-page layout is not as straightforward as it is in other layout views.
For this reason, single-page layout view, or website layout view, are necessary, instead.
6.3D2. Manually Write Page Numbers Before Relevant Text.
Screenreaders will not automatically read the automatically generated page-numbers (as footers), and can often only read page numbers if they are manually typed at the top of each page. Of course, even if the screenreader could read the footer automatically, the page-number is, by default, in the wrong place for anyone having to listen to the text. We need to know the relevant page-number before, and not after, we read the respective page.
So, where the original document contains page-numbering (such as in documents with more than 5,000 words), this exact numbering needs to be reflected in the SAF version, with the page-number being physically written into the document before the corresponding text on that page – e.g., [page 9] or [p.9]. The square brackets mean that the page-number is easily searchable without being caught up in page-referencing of cited works. It is very important that the page numbering corresponds to the original pagination, so that text can be referenceable – i.e., regardless of what the page-view in the SAF version is displaying.
In short, the non-alignment of the automatically generated footer page-numbers in the SAF version should not be of concern, not least because it is not automatically found by screenreading technology. What matters is that the text itself is preceded by its corresponding page-number from the original text, typed, not automatically generated.
6.3D3. No Gaps.
Especially where there are no substantial images in the original document, there may be a useful alignment of the pagination of the original print/.pdf and the SAF version. However, where images have been removed (while keeping the image description, of course), large gaps of space may appear if an effort is made to make the page-views of the SAF version look identical to the original. This means that the screenreader-user might find themselves reading through the space, not knowing where it is going to end. Such gaps should be removed in the SAF version. In other words, once the page number is written before the corresponding text, it does not matter in the SAF version whether the page-view itself aligns with the original.
6.3E. Full Editing Permissions.
All SAF versions should be fully unlocked – i.e., including the removal of all protected editing permissions. This is so that visually impaired readers can customise the document to make it more accessible according to their own personal preferences.
6.3F. Further Assistance.
For a practical and detailed description of how to make SAFs, a useful resource is provided by the University of Sussex:
https://www.sussex.ac.uk/brand/staff/web/accessibility/accessible-word-documents
However, where there are apparent inconsistencies between the University of Sussex document and this VVI document, we, of course, recommend that this VVI document be prioritised – (VVI being the representative voice).
If this document has been followed, we are happy to answer any questions or give further advice, as well as test the accessibility of electronic documents produced on that basis. We welcome all feedback at info@vvi.ie
6.4. PDF format.
If the default document is .pdf,this .pdf file also needs to be as screenreader friendly as possible. This is, of course, in addition to the necessary provision of the SAF .doc/.docx version described above.
To be accessible to screenreading technology, .pdf files must be fully tagged and properly structured.
In .pdf files, it should be remembered that the limit of 60 characters in Alt text boxes may not be sufficient to give a useful description of an image.
6.5. Email.
Firstly, a direct phone number to the person originating the email, should be contained in all emails.
Secondly, as with SAFs, in the bodytext of emails, tabulated text, textboxes or, images, and embedded information should not be used.
If hyperlinks are used in emails, they should be followed by the target address. This has several benefits, including:
*A. the recipient can know, before clicking, whether the wbsite is secure or not.
- the recipient can archive the contents in another format and fully access it later.
Also, as with all other formats, graphics should be adequately explained in text. In terms of logos, etc., we recommend your communications team asking whether the graphics necessarily add anything useful to your organisation or body’s email communications.