8 Myths About How Blind People Use the Internet

As a frontend developer of course I’d heard about 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:

Using a screenreader blindfolded to test websites

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. I asked HTML expert Jeffrey Zeldman whether we should be using title text in links, here’s his answer:

We're researching link title text, & how it's not used by screen readers. Is there any reason to use it you can think of?

@silktide says: We’re researching link title text, & how it’s not used by screen readers. Is there any reason to use it you can think of?

@Zeldman says: No! Do not use.

I wrote more about how I mistakenly thought title text improved accessibility here.

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 Internet Explorer and Firefox on Windows. 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. You might be surprised to know that Chrome, the web developer’s browser of choice, is only used by a small percentage of blind users.

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

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 new 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!

(2 Posts)

This post has been written by David Ball, a web developer and social media fanatic working at Silktide. Recently, David has been researching web accessibility to improve Silktide's automated website testing software, sitebeam.net.

Comments

  • I wanted to comment, but I couldn’t find this box.

  • In terms of the WAI-ARIA stuff, is this only available in newer version of screen-reader software?

    The reason I ask is I attended a talk last year, where the speaker talked about users who just couldn’t afford to keep upgrading their screenreader software, so you have to assume worst case when taking them into account.

  • Brenda Campbell

    David : While link titles are not read ‘by default’, they can and are used by screen reader users who have this attribute configured to be read, in their AT. As I mentioned in your other article, JAWS has the option to : 1) read both the title att and anchor text for every page, 2) read titles ‘on the fly’ for a single page by pressing INSERT+TAB which brings up a list of text
    link options, 3) read just the title attribute, 4) read the title attribute if no anchor text exists.

    It would be more accurate to say that link titles are not read automatically as they need to be configured to be read. To say that they are never read, is not correct. The problem with link titles is that they are not universally accessible or supported across browser and in touch devices.

    @gabel : Skip to content links are not just for blind users but an important navigation for other users as well (switch users, screen
    magnification, keyboard only, voice
    recognition and users who suffer from repetitive stress syndrome). For this reason it is important that skip links be visible so that all users can benefit from this function.

  • Guest

    Hi David : Re. link titles, as I mentioned in your other article, link titles can be read by AT if they are configured to be read. To suggest that they are never read by screen reader users kind of leaves the impression that it is not possible for AT to read link titles, which would not be correct. In JAWS for instance, link titles can be configured as follows : 1) both the title att and anchor text for every page, 2) ‘on the fly’ for a single page by pressing INSERT+TAB which brings up a list of text link options, 3) just the title attribute, 4) read the title attribute if no anchor text exists. The issue with link titles is that they are not universally accessible or supported across all browsers and devices, but for sighted mouse users they can be helpful if used correctly. The challenge is to present information in such a way that all users can access it.

    @gabel : I would suggest that skip links be visible rather than hidden, as they not only assist screen reader users but switch, screen magnification, keyboard only, voice recognition and users who suffer from repetitive stress syndrome.

  • kostas

    excellent work!However i am not sure about the presented myth about images with alt text and more specifically regarding your opinion”If the purpose of the image is for decoration only, alt text will be
    irrelevant and might confuse a screen reader 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.” From my point of view even if a text is being used for decoration purposes the alt text should provide also a detailed description about the meaning o that image with appropriate explanations e.g. this is a logo of the organisation, or this is a decoration image,…..etc..

  • Brenda Campbell

    If an image is for decorative purposes, it is best to leave the alt tag empty as in alt=””. This tells assistive technologies that image can be ignored.

  • You wrote:

    > 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.

    This statement is wrong and should be corrected. While it may be a best practice *today* to not rely on title text being available, due to it not being read by some screen readers, it is read by default in some (e.g. as help text in VoiceOver), and the W3C WAI expects it will be read by more as rendering engines start to fully support the ARIA text alternative computation.

    There is also an ARIA 1.1 proposal (@aria-help) that relates to exposing this information in all accessibility APIs. If that one goes through, @title would almost always be exposed, either as part of the element name computation, or as the default help text value.

  • Not sure about the WAI ARIA landmark myth. I’ve never actually heard anyone say it. Once someone knows about WAI ARIA, they probably know enough to understand that it’s a new standard.

    There’s a chicken and egg problem here. Screen reader users don’t use landmarks because almost no sites have them. Including it here makes it seem like they shouldn’t be used which will further reduce their use. If they we on all websites, I’m sure more users would use them. Also, the fact that they are implemented differently in different screen readers isn’t all that relevant. There are lots of things like that. The user of that screen reader just learns to use them as they are implemented.

  • Steve Faulkner

    When the title attribute is present but no other form of providing and accessible name (alt, label, aria-label, aria-labelledby, value etc depending on the element) the title attribute is used to provide the accessible name (i.e. in general what a screen reader announces). It is known that in general AT (VoiceOver being a notable exception) do not announce title attribute content on links by default. This is not an issue of not being able to (in general the title attribute is mapped to an accessible description property in accessibility APIs, when not being used as a fallback accessible name, and this has been the case for an extended time. But like browsers have not implemented device independent support for title attribute content even though it has been around and been an issue for 15+years, screen readers in general have not implemented support for it (in the case of descriptive text for links).

  • Neil Sayers

    I recently built a campaign website for the RNIB (Royal National Institute of Blind People) using WordPress, and was fortunate enough to have their Web Accessibility Team on hand to test and approve all my work. They were pretty demanding!

    I already knew about some of the points you raised, but I too was pretty surprised to learn that I didn’t need to add titles to links. In fact, to keep a consistent experience across the site, I was told to actively remove the title tags from links.

    I think the key things were: valid code and overall good structure for the code: correct heading tags, etc. Tabbing through links should also be clear and logical as well.

    I would possibly add a word on video content – I was told to integrate the Nomensa video player. Which is what the RNIB use site wide for wrapping their YouTube videos.

  • WillemSiebe

    Hi, great article. Which screenreader did you use in your tests?