Creating accessible content

Table of contents

Background

Norway has implemented the European Web Accessibility Directive (WAD), which aims to make public sector websites and mobile applications more accessible, particularly for people with disabilities.

Since 1 February 2023, Norwegian public sector websites – and this includes the journals on the Septentrio platform – have been required to meet 47 of the success criteria in the Web Content Accessibility Guidelines (WCAG) 2.1. A requirement to meet 35 of the WCAG criteria had been in place since 1 January 2021. See the English-language pages of Norway’s Authority for Universal Design of ICT for further information about the current accessibility requirements for web content. Documents (e.g., PDFs) published on public sector websites on or after 1 February 2022 should also meet the 47 success criteria.

Septentrio has checked the content on its webpages, including the PDFs, and found that collectively Septentrio journals fail on 15 of the required 47 WCAG success criteria. See Septentrio’s Accessibility Statement (currently only in Norwegian).

Accessible web content

Language of pages

The language of a web page needs to be identified so that braille translation software and speech synthesizers can read text correctly. If the user interface for your journal is English only, make sure that information you enter about your journal under Settings and Announcements in the OJS editorial interface is in English. If you have more than one user interface language (e.g., English and Norwegian), make sure you enter text in the relevant language in the appropriate language fields.

Headings

Sighted readers use headings to navigate content, and screen reader users need to be able to too. Are headings, e.g., on your “About” page, marked with HTML heading tags (of which there are six levels: h1, h2, h3, h4, h5, h6)? You can check by opening the source code for a given field (< > in the toolbar). Is your headings hierarchy logical? Avoid skipping any of the levels, i.e. going from h1 to h3 (skipping over h2) is bad practice. Note that the title of the page, e.g., Submissions or About the Journal in NOPOS, is a heading on level 1. See guidance on creating a headings structure in OJS (PKP), and an overview of WCAG criteria 1.3.1 Info and Relationships.

Lists

Content that has the visual appearance of a list (whether it has bullet-points or not) needs to be coded as a list. When working in the OJS editorial interface, click on the buttons for numbered and unnumbered (bulleted) lists in the toolbar to create lists. You can check your list is correctly tagged (ol for a numbered list; ul for a bulleted list) by opening the source code (< > in the toolbar). See guidance on creating lists in OJS (PKP).

Assistive technology provides users with a list of links on a webpage. When writing links, make sure your link text (i.e., the text users click on) describes the content of the link target (i.e., another website, a Word template, a PDF, etc.). Avoid using ambiguous link text, such as “click here” or “read more”, which cannot be understood without further context. Indicate relevant information about the link target, such as document type or language, e.g. (for 1700-tal), “Please use our article template (DOTX, svenska)”.

See guidance on creating accessible hyperlinks in OJS (PKP), and an overview of WCAG criteria 2.4.4 Link Purpose.

Alt text for images

Alt text (“alternative text”) should be provided for images so that this content can be transformed into other formats people may need (e.g., speech). Make sure to enter a short description of the essential elements or function of any image you upload (e.g., issue cover images) in the corresponding “Alternate text” field. See guidance on adding alt text to images in OJS (PKP) , and an overview of WCAG criteria 1.1.1 Non-text Content.

Author instructions

Metadata language

If your journal accepts submissions in more than one language, instruct authors which languages they should use for metadata (title, subtitle, abstract, keywords, etc.). These will usually be the language of the submission plus English. Authors can click on each metadata field to enter metadata in other enabled languages. If your journal does not have the necessary language activated, contact the Septentrio team. It is important that authors do not enter metadata in multiple languages in the same field as this will cause problems for screen readers and other assistive technology.

Word document submissions

If your authors submit articles as Word documents (DOCX), provide guidance on making their article content accessible. We do not recommend putting detailed formatting instructions (e.g., font specifications and heading alignment) in your Author guidelines. Instead, supply authors with a Word template (DOTX) for articles, with preset formatting for the types of content listed below (where relevant).

Passages and phrases in a different language

If an article contains passages or phrases in a language other than the primary language of the article, the change in language needs to be marked so that assistive technologies can correctly present content. Individual words and phrases in one language that have become naturalized in another (e.g. “rendezvous” in English) do not need to be marked. In Word, authors can mark text in a foreign language by selecting it and choosing Review > Language > Set Proofing Language.

Headings

Authors should use built-in title, subtitle and heading styles in Word. Headings should be used in a logical order. Read more about built-in headings in Word (Microsoft).

Lists

Authors should use Word’s list function to create numbered and bulleted lists, and avoid separating items with plain paragraphs. Find out more about creating accessible lists in Word (Microsoft).

Visuals

All images (illustrations, diagrams, graphs etc.) that are not purely decorative should be accompanied by a brief description of their main visual content. Descriptive caption text may be sufficient for this purpose. If not, authors should add alt text, but avoid repeating information also included in the caption, as this can be frustrating for screen reader users. Authors can add alt text in Word by right-clicking on an image and selecting “Edit Alt Text”. For more information, see Adding alt text to visuals in Word (Microsoft).

Authors should ensure that all information conveyed using color is either available as text, or also conveyed using patterns that do not rely on color. See tips from WCAG on Using color and pattern. Make sure that there is enough contrast between adjacent colors in diagrams, graphs and other figures: the contrast between a yellow line and a white background, for example, is unlikely to be sufficient. Authors can check the contrast between colors using WebAIM’s Web Accessibility Evaluation Tool, available as a browser extension. The contrast ratio between adjacent colors should be at least 3:1.

Tables

Advise authors to use Word’s table function to create tables, and to keep table structure simple (e.g., no merged or split cells). Tables should have headings for columns and rows. A brief description of tabulated content should be given as a caption or alt text. See also guidance on Using tables and table headers in Word (Microsoft).

Accessibility checker

Ask authors to run Word’s accessibility checker before they submit their manuscript (Review > Check Accessibility) and to address any issues identified.

Submissions as PDFs generated from LaTeX

LaTeX does not automatically generate PDFs with the tagged structure required by screen readers and other assistive technologies. Efforts to address this (not inconsiderable) challenge are being coordinated by the TeX Users Group (TUG) PDF accessibility and PDF standards working group. At present, however, there is no simple solution, and PDFs generated from LaTeX documents may require additional tagging, e.g. in Adobe Acrobat Pro, to make them accessible to readers (see below).

In particular, remind LaTeX users of the accessibility requirements for any images they insert into their documents. See the advice on visuals for Word users above.

Creating accessible PDF galleys

If authors have submitted their articles in an accessible format (e.g., an accessible Word document), producing accessible PDF galleys is relatively straightforward. You will, however, need to have Adobe Acrobat Pro installed on your computer (Acrobat Reader is insufficient).

Converting from Word to PDF

Elements in PDFs such as headings and tables need to be tagged so that assistive technologies can interpret them correctly. To ensure elements are correctly tagged when you convert from Word to PDF, choose File and select Save as Adobe PDF. Alternatively, select Save a Copy, click on More Options, select PDF under Save as Type, click on Options, and ensure that Document Properties and Document Structure Tags for Accessibility are checked, before clicking OK.

Make Accessible Action Wizard in Acrobat Pro

The Make Accessible action wizard in Acrobat Pro takes you through some of the most important steps needed to make a PDF accessible. Note, however, that some manual checks will still be required. To run the Make Accessible action wizard, choose View > Tools > Action Wizard > Open. In the right-hand pane, select Make Accessible. Click Start, and follow the prompts to, e.g., set the primary language for your PDF and add missing alt-text to any images.

The final stage of the Make Accessible action wizard is to run Adobe’s Accessibility Check. This covers many, but not all, of the WCAG 2.1 criteria. The results will be displayed in the Accessibility Checker panel on the left. Right click on any issues for guidance and suggestions for how to fix them.

See also Adobe’s support pages on Making PDFs accessible and Checking accessibility of PDFs.

Reading Order Tool in Acrobat Pro

“Logical reading order” is always flagged by Adobe’s Accessibility Check because it requires manual checking. Tags in a PDF should provide a logical structure that can be interpreted by screen readers and other assistive technologies. The tagged order should follow the reading sequence a sighted person would normally use.

Use Acrobat Pro’s Reading Order Tool to check and correct the reading order of a tagged PDF. First ensure that you are viewing your document in single page mode (View > Page Display > Single Page View). Then open the tool (View > Tools > Accessibility > Open, then select Reading Order in the right-hand pane). Contiguous page content will now appear as a separate highlighted region and be numbered according to its placement in the reading order. Select Page Content Order in the dialog box and check that regions are numbered in a logical sequence.

If content is tagged in the wrong order, click on Show Order Panel in the dialog box and drag and drop the numbered regions into the correct sequence in the panel on the left.

If non-meaningful content (e.g., running headers and purely decorative graphics) appears in the Order panel on the left, it needs to be tagged in such a way that assistive technologies ignore it. You can do this by selecting the page element and clicking Background/Artifact in the dialog box. In the Order panel, select the appropriate page element, and press Delete.

You can also use the Reading Order Tool to edit tags (e.g., marking paragraph text as a heading) and add or remove content from a tagged region. For further guidance, see the Reading Order tool overview (Adobe).