Lesson learned: Presenting Data to Visually Impaired and Blind Individuals

A few weeks ago, we began sharing our accessibility testing activities conducted on different types of digital products. In this blog post, we'll delve deeper into the findings and the lessons learned from testing the first product type: a data report containing various forms of data and graphs.

How to Present Graphs

Presenting graphs to blind individuals is not straightforward. Generally, screen readers interpret these as images, but there are measures that can be taken to overcome this hurdle.

To describe lines, pie charts, and bar graphs to blind individuals, three approaches can be adopted:

• If the editor used to create the report allows it, alternate texts can be added to graphs interpreted as images by screen readers, trying to depict what the graph aims to convey. When exporting to PDF or during presentation mode, it’s crucial to ensure that alternate texts are readable.
• To communicate the data within the graph, irrespective of its type, tables can be crafted. Tables are the most screen-reader-friendly data representation format and are easily navigable for those who use this assistive technology.
• If alternate text cannot be added and the table does not fully represent the data, it's beneficial to include a brief textual paragraph detailing the data in the report page.

Beware: screen readers don't read a paragraph in its entirety but break it down sentence by sentence. If paragraphs are not well-structured, users may lose the narrative's essence.

Inclusive Language VS Screen Readers

Another aspect we looked into was how screen readers handle "inclusive" language.
We attempted to incorporate the special character "ə", known as the "schwa", now commonly used as an inclusive language symbol.

Uniform results were obtained from our testing sessions: unfortunately, "inclusive" Italian text is currently inaccessible.
Screen readers don't recognize this special character and mispronounce the word, thereby disrupting the comprehension of the entire text. This is particularly evident when the schwa is used at the end of a definite or indefinite article.

Asterisks, truncated words, and other special characters are still challenging for a screen reader. It seems we're still far from achieving a product that is not only accessible but also linguistically inclusive.

Accessibility of Editing Tools and File Viewing

The last aspect we explored with this data report was Google Slides, the tool with which the report was crafted. This tool offers features to enhance its accessibility and the products created or viewed through it.

However, our tests revealed that Google's efforts are still inadequate. Even though the tool was unfamiliar to the interviewed users, it was clear from a navigation standpoint that the interface was far from accessible.

MacOS's VoiceOver couldn't delve into the slide contents, getting stuck on the tool's editor toolbar. This occurred in the editable mode, preview mode, and viewer-only mode.

We then tested the exported .pdf file and encountered more intriguing findings. Notably, the file reading changed based on whether it was viewed on a Windows or MacOS platform. On MacOS, using the default Preview PDF viewer, the document structure was well-optimized for VoiceOver compatibility. However, this wasn't the case when our file was opened on Windows with Adobe Reader and read using NVDA and Jaws (one of the most powerful screen readers available, also used academically).

A file that seems perfectly readable on a MacOS system may not be on a Windows system. Although we tried setting a different reading order from the screen reader settings, the reading was not entirely smooth but was more interpretable.

In any case, to ensure a document is genuinely accessible and easily readable for a screen reader, there are specific software tools available. These not only allow accessibility analysis of PDFs but also, in case of export or display issues, enable restructuring of the file to be more compatible with screen readers.