8 Myths About How Blind People Use the Internet


By

As a frontend developer of course I knew about the importance of accessibility. I’d always followed best practices when creating web content that shouldn’t have any problems being read by a screenreader.

Like so many other developers in my position though I’d never actually tried a screenreader myself. It always seemed like a difficult thing to do, and I’d heard it was expensive.

A few months ago I spent a week pretending to be blind for a week, using a screenreader to navigate websites, attempting to understand how a blind user will hear a site. I learned quite a few things that I didn’t expect that have changed the way I write HTML.

There’s lots of rumours and misinformation about accessibility best practices. Here are some myths that are definitely not true:

Myth: Screenreaders Read Link Title Text

This is not true, and surprised me greatly! For a long time I was under the impression that title text added to a link was intended to describe the destination of the link for screenreaders.

I’ve learned now that title text is actually NEVER read aloud by a screenreader, meaning adding information intended for screenreader users is completely pointless.

If this information is essential it can actually make your page less accessible.

Myth: Blind Users Use a Text-Only Browser

Don’t get confused between a screenreader and a browser, they aren’t the same. A screenreader reads the entire desktop, not just the web browser.

A screenreader isn’t a special type of browser, it’s just something that reads text from the software you’re already using. That means blind users will use the same browsers as everyone else.

I was mistakenly told by a fellow web developer that the best way to test a blind user’s experience is to use an obscure text-only browser like Lynx or w3m.

According to a study by WebAIM the majority of screenreader users use Chrome or Firefox. Testing your site in anything other than the common browsers might not be giving a true experience of a blind user.

Users of the free screenreader NVDA are most likely to use Firefox, which is recommended.

Myth: Blind Users Don’t Have JavaScript Enabled

How many users of any kind actually disable JavaScript? A long time ago I heard it was something like 1 in 10, but that was long long ago.

JavaScript is not only pretty useful these days, but for many sites it’s necessary to get the intended experience.

As blind users will use common browsers, it’s mostly safe to assume they’ll have JavaScript enabled too. It’s completely possible to make JavaScript interfaces accessible by screenreaders, using ARIA roles to enhance keyboard navigation.

Myth: Dynamically Loading Content is Bad for Accessibility

Social media sites like Twitter load content dynamically. For example, when scrolling down the page Twitter will automatically load new tweets so you don’t have to click “more.” I originally thought this would be an accessibility nightmare for screenreader users, but after speaking to some blind people I learned that it’s actually preferable to pagination.

Sure, there’s an awkward pause in the content that’s read aloud as the page is spoken, but this is preferable to going to a second page where you’ve again got to navigate through the headings and menu to the content.

This is still a bit of a hot topic though. I’ve read comments from some blind users who find auto loading content incredibly irritating.

It probably isn’t flawless in all occasions, but my advice is don’t dismiss it as inaccessible; if you’re developing a site that loads content dynamically, have a blind user test it first.

Myth: Blind Users Have CSS Turned Off

We’ve already established above that blind users use exactly the same browsers as sighted users. It’s unlikely screenreader users will disable CSS, and in many cases the CSS will affect how the screenreader reads content.

For example did you know that any page elements with the CSS property display:none won’t be read by a screenreader?

Many people think they’re helping screenreader users by providing a “skip to content” link at the top of the page, hiding to visual users with display:none. Actually screenreaders obey this and don’t read it aloud.

Myth: All Images Need alt Text

One of the very first things you might have learned about creating accessible webpages is to specify alt text on every image. This is still an important lesson, and giving appropriate alt text is essential to blind users using a screenreader, especially if the image contains text or conveys meaning.

However, not all images on your page require alt text. If the purpose of the image is for decoration only, alt text will be irrelevant and might confuse a screenreader user.

In these cases, you don’t need to specify any alt text at all. If this is the case, it’s best practise to show you intended to leave it blank by specifying an empty alt="" attribute.

Myth: Everything Needs a Tabindex

No it doesn’t, leave it alone! Tabindex is intended to solve the problem that the order a screenreader reads content might not be the best order for the content (it’s actually called “focus order” in WCAG 2.0).

If this is the case, you need to do some serious thinking about your content order, and not put tabindex in as a quick fit. Most of the time tabindex just makes things more confusing and can bounce users around the page in a non-logical way.

I tried to use a comments form on a blog last week, tabbing through each input box when I noticed the captcha box wasn’t included in the focus order.

After some checking with Chrome’s developer tools I found that the tabindex had been specified for each element except the captcha, pushing it way way down somewhere in the order of things making it very difficult to submit the comment using the keyboard.

Changing the focus order often causes more problems than it fixes. Put your content in a sensible order and leave it at that.

Myth: Blind Users Navigate Using Landmark Roles and HTML5 Structural Elements

You’ve probably seen the HTML5 structural elements like <aside> and <nav> which are intended to make more sense of our page content.

Also there’s ARIA landmark roles like role="main" and role="navigation" that we can add to our elements to indicate their purpose. This is definitely going a long way to making our content easier to navigate, but adoption of these new technologies still has a long way to go.

The WebAIM survey shows that almost 35% of people seldom or never use landmarks.

It’s not a bad percentage, but each screenreader and browser combination does something different, and not all websites make use of landmark roles, so it’s not a reliable method to use.

The largest percentage of screenreader users use page headings to navigate, skipping from one to the next using a keyboard shortcut.

When trying this out myself however I realised how easy it is to skip an important piece of content, especially if the website author hadn’t used headings correctly.

This myth’s debatable. In the future I believe users will navigate using structural elements and ARIA roles a lot more than they currently do as it becomes more reliable, but remember this isn’t the only way screenreader users navigate.

Summary

Like so many others, I learn by doing. There’s been loads written about creating accessible websites, but much of it is boring and theoretical.

Simply by using a screenreader myself I was able to learn so much more about how a blind user navigates a webpage, and how to create better websites.

Obviously though, blindfolding yourself can’t give a true experience of being blind, so what I really recommend is get a blind person to check your sites, or at least teach you how to use a screenreader properly.

I’ve had some great conversations with blind users recently after publishing my first article about accessibility, and there’s a lot you can learn by just asking. If you’re a practical hands-on kind of guy like me, trying it out yourself is a valuable experience!

Related Topics


Top
This page may contain affiliate links. At no extra cost to you, we may earn a commission from any purchase via the links on our site. You can read our Disclosure Policy at any time.