Seeing our way - Accessibility for the web and print

July 2018

Image of the lovely Sarah Maclean looking sharp in her red blouse and dangly earrings. She's wearing glasses and a winning smile.Frankly, I loved Sarah and Harriet’s webinar: Seeing our way - Accessibility for the web and print . A world unfolded before my eyes, if you can excuse the turn of phrase, and suddenly I was seeing things in a new light (no pun intended). Some of the things they said seemed so obvious in hindsight I was ashamed to have missed them for so long. And some things were so different from my experience of the world as to be utterly fascinating. I came away with a pile of notes and immediately pounced on poor Sarah for a follow-up interview on improving TechCommWire.

I’d like to take a moment on that note to thank Earnsy Liu for her great work on What’s The Evidence which, according to Sarah, is consistently the best of our regular articles in TechCommWire when it comes to accessibility, especially her alt text.

Image of Harriet Kay, looking super stylish with her matching red blouse and red lipstick.

One of the most interesting things I found out was that problems can arise from the strangest and simplest of places when it comes to accessibility. When Sarah was working with Harriet on improving the alt text of images in a document, they encountered one almost straight away.

“Here’s the first draft” sent Sarah by email. “Please give me detailed feedback!”

“Thanks for your help,” read Harriet’s reply.

Now, as Sarah said, that was polite but not exactly detailed. After a few back and forths, it came to light that Harriet wasn’t getting what Sarah sent, and in fact didn’t know there was anything to read.

It came down to a simple software incompatibility between Sarah’s Microsoft Office Software and Harriet’s Apple Voice Reader. “Surely not in this day and age!” you cry…

…but it turns out it’s a common problem. Said Sarah: “It doesn’t matter what your software says about accessibility, if your user can’t use it, it ain’t accessible.”

In fact, many people use multiple Voice Reader tools from different providers in order to overcome this exact issue.

Voice Overs or Voice Readers are amazing things, but frustrating to use if you don’t know how. This means they can also be frustrating to write for. In previous years, they weren’t part of the operating system and you had to download one externally. This was quite limiting, not only because of the cost involved, but because they were also highly specialised and if you don’t know what you don’t know, you don’t know if you’re getting the right product. These days, most operating systems come with a built-in Voice Reader, which is easily customisable but may not be compatible with other products. The most common is, of course, the Apple/Windows divide, but it’s far from the only one.

Voice Readers are far from perfect, but they are generally regarded to be the best way for a blind or low-vision reader to read content. As a writer, it’s important to remember that these are not the only people using Voice Readers. Readers with dyslexia, which is relatively common, find it a lot easier to consume content this way, particularly if they are short of time or the document is long.

So, how do you write something, bearing in mind that some of your readers will be using a Voice Reader?

A Voice Reader will read text left to right, top to bottom. So far so simple. Except that it will also read out every single punctuation mark. You can toggle around the page with the tab button or keyboard shortcuts. However, if the webpage hasn’t been set up properly, e.g. using headings, you can’t use the keyboard shortcuts and navigating becomes a bit of a mission.

It’s worth remembering that you can’t click on anything if you can’t see what you’re clicking, so hearing your Voice Reader tell you “for more information, click here” in a robotic monotone is less than helpful. It’s better to think of the toggle function and simply state where to toggle to. “Go to Information” for example.

Voice Readers get to an image and just read out the alt text without really stopping, so it’s important to make it clear both that it is an image, and what the image is of. A lot of those in-built accessibility functions will fill in alt text for you these days. That’s okay, and better than nothing, but not ideal.

How do you write good alt text?

Nobody likes to feel like they’re missing out on content that could affect how you feel or think about something – the more description the better!

We’re including an image for a reason, so keep the reason in mind when writing the alt text. You don’t want to spell out that the picture implies something positive for the article, just let the meaning come through in the alt text. Explain, don’t interpret. That’s your reader’s job.

If there is text in the image, spell it out. Nobody is going to know that the TechCommNZ logo says “Technical Communicators Association” if you don’t tell them.

Your readers have an imagination! Let them use it! Don’t just say “TechCommNZ logo” …tell them it’s “a circular blue and green network diagram”. Don’t say “a man sits in front of a body of water” …describe what he’s wearing, doing, what the background is. What colours are used? All of these things impart meaning to us as viewers and that doesn’t change just because you’re viewing with a Voice Reader.

What about colour?

While we’re on the subject, it’s worth remembering that Red-Green colour blindness is a lot more common that you think. We’re pretty well conditioned to put warnings or negatives in red and good practice or positives in green. Unfortunately, that’s just no good to someone seeing both as a shade of brown. Better colours to consider are orange, yellow or grey. Incidentally, that’s also why the universal default colour for hyperlinks is blue.

But it’s not just colour, it’s contrast. Yellow writing on an orange background is going to make people in the normal vision spectrum struggle, let along people with low vision or colour blindness.

Sadly, there’s no universal best colour practice but try to keep these things in mind.

How do I include a hyperlink if the user can’t click it?

First and foremost, make it obvious that it’s there. Remember that Voice Readers don’t announce what they’re about to read or pause to tell you they’re about to read out a hyperlink or image. They just keep going like it’s part of the sentence.

Write unique and descriptive hyperlinks for images and webpages. Not everyone is going to want to follow the hyperlink, but you need to give people the option. A descriptive hyperlink might be the name and author of the article you are linking to, the name of the page or website, or a short description of the image.

A simple example is: “Read About Us to learn…” versus “ Click here to learn…”

Do we still need large print versions when you can enlarge text on your screen?

Large print is a good idea. While many devices come with handy built-in options for enlarging text, sometimes your only option is zooming in. And as you know, that’s only helpful until you hit a blurry overlarge image or have to scroll for miles to see the other end of the sentence.

It’s relatively easy to make a large-print version of most documents, print or PDF, and comes with the added bonus of giving people lots of room to scribble notes in the margins… or it should.

Contrary to what you might think, large print means Large Print. Size 14 might look big when you’re used to working in Calibri size 11 but it’s just not big enough to be helpful.

Some tips:

  • Don’t capitalise whole words. Capital-Lowercase contrast makes things a lot easier to read (that’s why they do it on road signs!)
  • Your body text should be size 18. Your titles should be 24.
  • Double space. White space is your friend.
  • Pick a Sans-serif font and try to avoid Bold or Condensed fonts which are harder to read.

Working with the end users

  • A little forethought goes a long way as my Grandma would say.
  • Give information about meetings in advance, and in large print and e-version.
  • Publish all versions of a document at the same time. Nobody should have to wait for a print version while others are reading the e-version.
  • Use Plain Language (always!)
  • Use styles and formatting. This makes things so much easier to navigate with a Voice Reader because you can toggle or shortcut to different headings.
  • People don’t always know what they don’t know. Ask them about the software/hardware they use and their experience with IT. Ask them what they need. Work together to find the best solution!
  • It might not always be easy to adapt your standard practice, but with a little thought and consideration it can be done. It is always appreciated that you are trying. You don’t need to be an expert. Involve end users from the start. They’re the ones with the first-hand knowledge.
  • When in doubt, ask!

Sarah explained “we called this webinar ‘Seeing our way’ because it’s a statement of positive intent that you often hear in business and the community. ‘Yes,’ you say, ‘I can see my way to doing that…’ I am often feeling my way in this work. The commitment is there, and the feeling that it is all possible.”

I don’t know about you, but I for one can definitely see my way to improving TechCommWire’s accessibility, and the rest of my writing as well!

If you’re interested in following Earnsy’s example, visit the Best Practice Round-Up under Resources on the TechCommNZ website.
https://techcomm.nz/Story?Action=View&Story_id=248
techcomm.nz
crawl=CC-MAIN-2018-47
43452
application/http; msgtype=response
sha1:D4AHBFPWKP5NGKE6NNL7XZHAG6DMICIU
<urn:uuid:d33d961f-3a93-4cfe-ac06-0dca477035e8>
2018-11-14T11:21:40Z
202.27.193.185
text/html
sha1:VUBFIPMKYPL6OAEDFY2LO2PPAIX7KF6O
<urn:uuid:26397d28-659b-4a0c-a09d-26fc908e23e2>
https://techcomm.nz/Story?Action=View&Story_id=248
response
<urn:uuid:eb57bf52-6eb9-43fc-9cd3-101e5aa94278>
isPartOf: CC-MAIN-2018-47
publisher: Common Crawl
description: Wide crawl of the web for November 2018
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-166-161-213.ec2.internal
software: Apache Nutch 1.15 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 0.11-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/