If there are editors, administrators or others who publish content for end users, they must receive guidance on producing content that complies with accessibility standards. For example, editors who publish content for the AU website using the AU website system. Teaching staff who create course material for students using the AU LMS. And users of Conference manager, who set up conferences that external participants can register to attend. In the following, these editors, administrators, etc. will be referred to as ‘content producers´. It is the responsibility of the system administration to provide guidance for content producers depending on the types of content covered by the system.
If the system uses informative images, a visually impaired person must be able to have the image “read aloud”. Therefore, content producers must provide a description of the content of an image in the alternative text field. If the image is purely decorative, the alternative text field should remain empty, so the screen reader knows that the image has no significant meaning to content.
Furthermore, content producers should refrain from creating images that include text. Screen readers cannot detect text on images.
If the system contains an editor that allows the content producer to define a number of parameters for the text, it is important that the parameters comply with accessibility standards. For example, indicating whether something is a headline, bolding text, creating lists, tables, etc. The more options for text design that a system offers, the greater the risk that the content producer will create text that it is difficult for a screen reader to read.
Typical errors in connection with text and accessibility:
Bolding a text instead of marking it as a headline. A typical navigation method for the visually impaired is to have all the headlines on a page read out loud in order to gain an overview of the content and structure of a page.
Using hyphens rather than a list function. It is important to use the correct marking, because the screen reader informs the visually impaired person how many items are on a list, so that they can gain an overview of the number of points (an overview others gain visually).
Using bold text instead of row and column headings in tables. When a screen reader reads a table, it reads the row and column headers out loud before reading the content. If there are no headings in a table, the data will not make sense for the visually impaired because they do not know the context.
Using link names such as "read more" or "click here" instead of a text that explains what the user can find by clicking the link. Another typical navigation method for the visually impaired is to have all links on a page read out loud. If links just say 'read more' or 'click here', the visually impaired person will not know what they are referring to.
Visually and hearing impaired people should be able to use video content. Video material uploaded to the system must, therefore, be subtitled. However, video content produced prior to 23 September 2020 and live videos are exempt.
Audio content must also be accessible to the hearing impaired, and this means that uploaded audio content must be transcribed. However, audio content produced prior to 23 September 2020 and live audio contents are exempt.
PDFs are one of the major focus areas of web accessibility. PDFs have some of the same challenges as the typical text errors described above. A screen reader cannot gain an overview of the headings, tables, lists, etc. unless they are specifically marked when the PDF is generated.
Content producers are advised to minimise the use of PDFs and instead copy content directly into the system. You will therefore be able to use the accessibility tools already available in the system. Furthermore, it is good practice to reduce the use of PDFs as they generally provide a bad user experience on mobile devices due to a lack of scaling (you often have to zoom and scroll horizontally to read a PDF file on a mobile phone).
If a PDF is necessary, you can use the accessibility tools available for Word or Indesign, which are often the basis for PDFs.
Furthermore, all employees have access to Adobe Acrobat Pro, which can test the web accessibility of the final PDF file.