Things I learned by pretending to be blind for a week

David wearing blindfold using a screenreader

I’m a full visually-able user and I love looking at websites. I know though, that not everyone experiences websites in the same way. Browsing websites at different screen sizes is a hot topic at the moment, but lets not forget that it’s not just mobile users that experience websites differently, blind users experience them in a way you might not even realise.

So I started using a screen reader to see (I suppose I should say “experience”) how a blind user navigates a website. First I want to say accessibility isn’t completely new to me. I’ve been creating W3C valid websites for years, building to web standards, and always taken care to make sure all my images have alt tags, and any Flash has an appropriate text alternative.

However, when I started using a screen reader, I learned quite a lot.

1. A screen reader reads the entire desktop, not just the browser.

Somehow in my ignorance I assumed the screen reader was just the browser, but it’s not, it’s the entire operating system experience. From turning your computer on, you need to navigate using keyboard commands to the browser and open it.

If anyone tells you that a good way to experience websites as a blind user is to use obscure browsers like lynx or w3m (as someone tried to tell us on our Facebook page), just remember that it’s unlikely you’re getting the same experience as the majority of blind users.

2. It’s difficult

The learning curve is steep! Getting to know the keyboard shortcuts just to move around the page is difficult, as is remembering where those keys are on your own keyboard when you’re blindfolded! Oh yes, I did blindfold myself for the full experience, not at first, but gradually once I became more confident I knew what I was doing. Often I would navigate myself into a corner or option that I was unfamiliar with though, and had to take a peek to discover what had gone wrong.

Here’s a sample of what happens when you navigate to a page using a screen reader, it starts to read out every piece of content on the page, and I mean EVERY piece of content, and doesn’t stop until it’s melted your brain and the words merge together into a sea of electronic voice. If you want, you can listen to the entire page, but I learned from this screencast by visually-impaired user Robert William that it’s actually much better to wrestle for the control and navigate through the content yourself. Be prepared though to be baffled by hundreds of links and headings before you even get to the page content, or the link you want.

3. It’s different between browsers

The most popular browsers for blind users (according to WebAIM in May 2012) in Internet Explorer 8 (30.4%) and 9 (28.5) and Firefox (20%). My favourite browser is Chrome, which I started using, but soon realised the experience was very different between browsers, so switched to Firefox which actually does a very good job of accessible navigation.

It was when I viewed a page created by accessibility researcher Sina Bahram to demonstrate good accessibility that I discovered that Firefox automatically adds a landmark HTML5 <nav> elements without having to specify an ARIA role. I asked Sina why he didn’t add a role=”navigation” to the element, which I thought was standard practice, and he replied:

“when there’s an actual HTML5 element to do the same thing, I tend to use the element. More semantic.”

He’s right, but of all the browsers I tested, this only created a landmark in Firefox.

There’s a video of Sina demonstrating accessing the web using a screenreader here.

4. You have to learn to listen fast

I once realised when watching a DVD on my Playstation 3 that you can set the speed to 1.5x. Which means you can finish watching a 2 hour movie in only 1hour 30 mins and still understand what’s going on. “That gives me 30 minutes of life back!” I said excitedly at the time, and started to fry my brain listening to their speeded up chipmunk voices. Of course I couldn’t take the unnatural high speed pace, and changed it back to normal pretty quickly. But that’s nothing compared to the speed Sina Bahram listens to his screen reader (see the first 40 seconds of the video linked above).

Even at a relatively casual pace though, it’s a lot of information to take in at once and often I would have to go back and listen again to the page options I’m given.

5. Some popular websites are very difficult to use

I was trying to use my screenreader to browse to the websites I use on a daily basis. Facebook, forget it. Despite articles telling me how accessible Facebook is in theory, the JavaScript and infinite scrolling page caused my screenreader to slow my computer to a crawl before I’d even started. In visually-impaired user Robert William’s screencast, he has issues with Facebook too, so uses the much more accessible mobile site.

I also tried, but couldn’t get off the homepage which had over… wait for it…. 1000 links! But it was very difficult to navigate to the main search box to search for an item (I actually thought it was impossible for the first few times I listened to the page, before finding it nestled between two other options), and had absolutely no ARIA landmarks. Very disappointing. A quick chat though with a blind friend of mine convinced me to use the much more accessible mobile site which worked much better. Still, a very aggravating experience that I had to find and use the mobile site instead, something I wouldn’t have done without experienced user knowledge.

6. Link titles aren’t helpful

This is one of the most surprising things I found actually. I’d always assumed text added to a link using the “title” attribute was read aloud by a screen reader instead of the link’s normal anchor text, allowing you to write useful information about the link’s destination. But it turns out, it’s not used at all. Ever. Except the rare time there’s no link anchor text at all. So any supposed “useful” text written in a link’s title attribute is completely inaccessible to a screen reader.

So don’t assume you can get away with plain links like “click here” or “read more”, and provide descriptive title text, because it’ll never be heard.

I even asked HTML expert Jeffrey Zeldman on Twitter if there’s any reason to use the title attribute at all, and he replied “No! Do not use.”

@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"

7. Autofocus is annoying

Any website that steals the focus for an input box is going to confuse a blind user. Imagine reading through a page, when the JavaScript hijacks your screenreader’s voice and jumps it to somewhere completely different. You now have no idea where you are, if you’re at the top of the page, or at the bottom. You’re disorientated and could miss some really important content.

8. Being W3C valid means jack

I’ve always sought to make my websites pass the W3C validator, but even with a big shiny green tick, you’ve barely even begin making your site accessible. I know there’s only so much you can look for in an automated test, but there’s a vast amount you can do to make your website a better experience for blind people that can only be discovered by real user testing.

9. It’s easiest to navigate using headings

After hearing so much talk recently about ARIA landmarks, and the enthusiasm for semantic HTML5 elements, I expected there to be a way to navigate straight to different sections of a website quick and easy. Especially with elements like <header>, <nav>, <aside> and <footer> I thought I’d be able to skip to these elements quickly. Well, you can… if every website had them. But surprisingly so many don’t, neither do they have the ARIA landmark roles, like role=”main” for the main content, or role=”navigation” for the site’s main links.

What I found myself doing mostly was either the laborious process of reading through each piece of content, or skipping to the next heading, which was much more reliable than searching for non-existent landmark roles. At least most web developers use headings correctly, which is why this is the only reliable method of navigation around a page.

Here’s a video of a guy navigating through webpages mostly using headings.

10. Blind people are very good at keeping their rage under control

What I really mean by this last point is, it’s frustrating. Having to listen to a billion links as they whiz past your ears takes a lot of concentration, and is incredibly infuriating if a lot of them are unnecessary.

It’s clear many websites don’t cater for blind people, presumably just due to a lack of testing or maybe just the harsh reality that they don’t have enough time to cater for such a small portion of their audience. I think we’ve got a moral obligation however to help blind users navigate the web, and having experienced it myself, make it a less hideous experience.

If you enjoyed this, follow us on Twitter and Facebook.

Watch quick video tour of Sitebeam

Test your website with

or see prices & plans
  • David Higley

    Intersting stuff! Did you find any stats about what devices visually impaired people are using today? Is it still mostly JAWS on a PC, or have people moved to NVDA (free JAWS alternative) or onto tablets?

    • David Ball

      Hey Higgers! The best stats I’ve found were collected by WebAim in May 2012 The most popular setup is JAWS on Windows, with NVDA coming second and getting more popular since last year

  • andydavies

    We tend to focus on blind people when talking about accessibility but it’s worth remembering that they’re not the only ones with accessibility needs e.g. dyslexia, eye issues where low contrast or high-contrast colours pose problems (can’t remember what they are called), motor problems etc.

    • David Ball

      Very true Andy! All sorts of disabilities have to be taken into account, obviously though I chose this one because it’s a bit easier to replicate. I can’t temporarily make myself dyslexic!

      • John Bevan

        I wonder if someone could knock up a script to recreate the dyslexic experience? i.e. It would go through content and swap a few letters around / remove short words so that a regular user would see what a dyslexic person experiences. Weirdly I’d never considered this issue despite being dyslexic myself (probably as I have a very mild case and had a tutor to help get me past the worst of it when I was young).

        • simon

          I don’t think you could recreate this, since even in the case of swapping a few letters here and there, your (well, maybe not yours if you are a bit dyslexic :/ ) own brain would sort them out instantly or so. Like the texts where every word has its first and last letter right, and all the other mixed : you are sitll albe to raed, although slower. Simple theory from me, though.

        • simon

          I don’t think you could recreate this, since even in the case of swapping a few letters here and there, your (well, maybe not yours if you are a bit dyslexic :/ ) own brain would sort them out instantly or so. Like the texts where every word has its first and last letter right, and all the other mixed : you are sitll albe to raed, although slower. Simple theory from me, though.

        • andydavies

          Aren’t there are number of factors behind dyslexia and different experiences i.e. it’s not a case of letters being jumbled? (

          • Cub3

            Personally I am a dyslexic web developer, you learn to live with it, I do jumble up words / numbers but I have to say the only way having dyslexia negatively effects surfing the web is god damn captchas, if your website has a captcha.. I am screwed

          • annag

            Do audio captchas work for you?

          • maco

            Have you ever tried listening to ReCaptcha’s audio alternative? It sounds like this: MRRRRRRRRRRRRRRRRRRRR That’s it. Just one long sound. It does not recite the letters and numbers at you. I can only hope that other Captchas with audio alternatives do better.

          • maco

            Yep, not being able to tell b, d, p, and q apart (notice how in the font used on this site they’re the exact same shape just rotated/flipped?) is a common problem, as is “the image on the left…” “left? left…left…which one’s left?”

        • Sumana Harihareswara
  • Richard

    Why do blind people need a screen at all? Why do they need Windows?
    Surely someone needs to think of the whole experience from a blind persons point of view and also an add-on to the keyboard that has prev next.. and some of the shortcuts built in an easy formation?

    • David Ball

      Haha Richard you’re right, I only used a screen so I could peek occasionally when I got totally lost on the page. Obviously blind users don’t have that advantage! Cursor keys make good prev next buttons, and you can navigate around the page using hot keys that take you to the next link, form, heading, paragraph etc. There are plenty of shortcuts built in, and I understand that many blind users create their own to customise their experience, which is great but unfortunately means every blind user could be having a completely different experience!

      • Stomme poes

        Remember all those screen reader users with some sight, or dyslexics, and of course families, offices, etc with seeing and blind people! Screens are useful, and Windows is currently the most popular OS for individuals. Though I keep hearing how awesome VO is on the Mac, and VO being available on iPhones makes iPhones one of the most popular phones today for the well-moneyed blind and low-vision…

        Also Richard the navigation possibilities in current screen readers are *way* better than just limited Next and Prev :P

        • Niklas Berglund

          “and VO being available on iPhones makes iPhones one of the most popular phones today for the well-moneyed blind and low-vision…”
          – VERY reasonable price to pay for such an aid.

    • j_meissner

      What an ignorant and unsolicitous comment.

      Why they need a screen? Probably because they are not lonely people which only communicate with “non-seeing people”, what an ignoble question you made there.
      Why they need Windows? Probably because most of them still work, and not all of them at home. In fact I know a blind freelancer who does code review for me.

      Hey Richard, just a hint, live your life so you don’t get too old. Because your eyes are useless to work with the computer like you do it right now from your age of 65. And if most people think like you NOW, don’t expect to have a happy life THEN ..

      • James Shakespeare

        Way to completely misunderstand his argument

      • anon

        I honestly think you misunderstood richard.

        There is a reason why the ipad or the iphone does not have windowed application. One is screen real estate but more importantly its the context. When you are on the road, you don’t have the ability to navigate a complex windowed system. You need a simplified system that allows you to work in that context.

        The context for blind folk on the other hand is very different from the non-blind. Just like the desktop user from the mobile user. An interface for the blind needs to simple and straight-forward. It does not need a visual interface (a screen); it needs an audio interface.

        Using the desktop interface on a mobile would make for a horrible experience. Just like a visual interface for a blind person makes for a horrible experience.

      • Nik Dudnik

        Did you really read the Richards post?

    • Adrian Edioma Migraso

      nice new product for the blind — screenless pc!

      • Aaron

        My friend Quinton used a headless computer for years called a type and speak. It was like a thick keyboard with an audio out jack.

    • Sue Basko

      Most people categorized as “blind” are not totally without sight. They are visually impaired in some way or other. Many have some vision. Tthe biggest problems are with glare and contrast.

    • Michael

      The majority of people medically classified as “blind” actually still have some vision remaining. There are very few completely blind people in the world.
      The monitor can still be helpful for colour, general movement and sometimes largely magnified text (think 3-4 characters on the screen at a time).

  • Caryn Humphreys

    This is an interesting article considering the AODA Compliance dates that are creeping ever closer in Ontario. AODA makes accessibility a requirement for all new websites created after 2014, or any website generating significant new content… so it’ll be interesting to see how many new things we learn as developers and designers get more involved in making their websites accessible!

    • David Ball

      Thanks for commenting Caryn, I’ve not actually heard of the AODA Compliance in Ontario, but I’m glad to see it become a requirement. Although there’s a big different between making a website “accessible” and “usable”! Many of the websites I tested would probably pass basic requirements for accessibility, but are still difficult to use.

  • Brenda Campbell

    Good article that highlights some of the challenges that blind people encounter and is good food for thought when designing with screen readers in mind.

    Regarding Richard’s comment, although a poor choice of words used, there is some validity to the comment about monitors. Many blind users do not turn on their monitors but some I have worked with do so in the case where a colleague is reviewing something with them and needs to see what’s on the screen. The other comment regarding Windows on the other hand, is completely short-sighted. Of course screen readers need an operating system like Windows! Why should their computing experience be any different from a sighted persons? Many power users are able to configure their own set of access keys and short-cuts making the job of getting around a web page a lot easier.

    Re. ARIA landmark roles and why some websites don’t have them. The reason is two-fold I think. Not everyone is up to speed on ARIA and at present there is inconsistent level of support in some browser/screen reader combinations for handling some ARIA roles.

    Regarding the section on ‘Link Titles’, JAWS for instance is a screen reader that does not read titles out of the box but must be configured to read these attributes. As far as ‘read more’ and ‘click here’ links, these should be avoided but there is a way to make them accessible in adding a span with additional information (that is only available to the screen reader) to describe the target when the link is accessed. Ultimately, link text should be explicit enough so that titles and the above workaround are not necessary.

    • Stomme poes

      ++ Brenda, great comment! And we can safely tell webdevs in most cases that if they have the opportunity to add in ARIA landmark roles, to do so without worry of anything breaking. The worst (besides maybe using the wrong landmark) is the browser will skip it silently.

      • Brenda Campbell

        Yes, true enough. Kinda like JAWS when it doesn’t have title att configured!

        • silktide

          Brenda you say JAWS can be configured to read title attributes. My understanding that this will read the title instead of the anchor text, which might give a worse experience depending on the website. Is this a setting you would recommend to other JAWS users or not? Do you know at all what percentage of JAWS users have this setting enabled?

          • Brenda Campbell

            It depends on how JAWS is configured. By default, it reads link text but it can also be set to read 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. If using title att it is obviously very important to ensure that this is unique, in other words does not replicate or replace anchor text but provides meaningful information to describe the target. That said, the title att is not ideal for universal accessibility as it is not available by default to sighted keyboard and mobile users.

            Re. JAWS users and title att enabled, I could only make the assumption that I think the population of JAWS users is probably advanced and use it according to their preferences.

    • John Foliot

      Re: Operating system/Windows – all Assistive Technology runs on top of an Operating system, be it Windows, MacOS, Linux, etc. – these OS’es have built in Accessibility API’s ( ( which are the ‘bridges’ between the system and applications (note David’s observation that screen readers interact with all aspects of the system).

      With regard to support for ARIA in the browsers + AT, it is actually quite good today (providing the end-user is keeping up-to-date with their software) and so I would encourage all developers to dig a little deeper, and start using ARIA where-ever and whenever they can: certainly ARIA landmark roles (which map nicely and neatly with the emergent HTML5 landmark elements) – for backward compatibility I would recommend today to use both (for example )

      • Stomme poes

        I’m old-fashioned. I like the lack of extra tags and do ul role=navigation (I haven’t yet had an actual div or larger object who could count as navigation yet… that would be a time for nav)

      • Brenda Campbell

        Yes, of course. Good point John re. SRs, operating systems and more specificly browsers. SRs couldn’t function without them!

  • fjpoblam

    Regarding link titles not helping the blind: if they are never read, then I take it they do no harm. Right? However, they pop up on hover for *sighted* readers. So, if I wish to include one now and then, I should not be “called to court”?

    • silktide

      Hi, yes you’re right actually. They do no harm as long as you’re not under the impression that they’ll actually help blind users. If your anchor text is descriptive enough, an additional title text won’t do any harm.

    • Felix the hat

      I use them as a easy ‘tooltip’

    • Felix the hat

      I use them as a easy ‘tooltip’

    • Ryan Benson

      Actually it depends on the Assistive Technology that you are using. David didn’t mention what screen reader he used, but I assume he used NVDA since it is free. I haven’t monkeyed too much with NVDA, so I don’t know the inns-and-outs, but by default JAWS does not read the title attribute. However you can enable it to read out the value.
      On the other hand, ZoomText, which is used by people with low vision (and sometimes people with learning disabilities), reads the title attribute INSTEAD of the linking words. I only have ZoomText v9.1, and there is not an option like in JAWS to choose. (They may have added it in v10) So if you bloat title attributes to help SEO or whatever, you can cause confusion to the user.

      • Stomme poes

        The ZOOM bug! When will it die???

        Also Nielsen showed how often link titles got in the way of other text, such as on Mega Dropdown Menus. I personally have a lot of trouble on LinkedIn when trying to see the name/occupation that appears when I hover over someone. Their stupid repetitive name title only gets in the way and helps nobody.

        And hi Ryan :P

    • Ted King

      P.S. The article refers to the “title tag” (<title>) which is in the header section of an HTML document. It should be referring to the “title attribute” which is part of the anchor tag (<a …>) which can be found in the body section.

      • silktide

        You’re right Ted, there was 1 incorrect mention of title tag, which I’ve changed. Thanks for spotting that!

    • Dawn Budge

      Take a read of this:
      The RNIB is the Royal National Institute of Blind people, a UK-based royal charity who do some good education work with the developer community.

    • fjpoblam

      All these replies to me are, of course, enlightening. I hope those authors will excuse me for blanket-replying to them by replying to myself. How I use titles. (1) I *seldom* use alt for images (or, more accurately I use alt=” for validation) because *my* sites are so simple-minded that images are just for visual appeal. I concentrate on text. No titles there, either. And (2) link text, *when* used —which is not always— is for explanation. E.g., a link to ASPCA may contain “American Society for Prevention of Cruelty to Animals.” An exaggerated example, yes, and not a real one. But it shows a case in which I’d rather not litter the *text* with a drawn-out explanation of the thing being linked. An explanation not *essential* but perhaps “entertaining” or in some minor way “useful”.

  • Dude

    Interesting. It seems to me that it’s not the job of every web designer out there to dumb down their sites so that screen readers can use them, why not pressure the makers of this shitty screen reader software that doesn’t read anchor title attributes to make better software? There’s no reason why this can’t be better and allow use of sites with heavy javascript/etc.

    • John Foliot

      DUDE! It’s not about dumbing down your web site, on the contrary it is about making it more intelligent and useful for all users, and not just those with 20/20 vision. Adding useful structural information such as aria landmarks, thinking about your alt text (3 buttons with the alt text of button, button, button is dumb), and limiting the number of links on your page (which is an usability problem for more than just non-sighted users BTW) aren’t dumb things to be doing, they’re smart.

      To set the record straight, screen reader users can access pages with JavaScript (and in fact, JS libraries such as jQuery core have a lot of ARIA already baked in), but if your JavaScript is stealing focus, then it’s not the screen reader at fault, it’s the Dude who wrote the script to blame.

      As for why screen readers don’t read @title… well, by default they don’t, however there are user-settings that can increase the ‘verbosity’, at which point users can be informed of the title info (also, contrary to what the author wrote, @title will be used in form inputs as a fall-back when s are not used – it is the exception to the rule. As for why… it’s a historical problem as much as anything else: back in the late ’90′s or so, Internet Explorer (3, I believe) started generating “tool tips” for @alt text, but Netscape didn’t: to get tool tips in Navigator you had to use the @title attribute. This resulted in authors ‘doubling up’ the values of @alt and @title (to get tool tips on both browsers), which resulted in the screen readers speaking double speak on every image (screen reader when encountering an image: “image: Amazon Logo”, or when doubled-up, “image: Amazon Logo, Amazon Logo”) – so you can see why the screen readers had to settle on a default behavior of ignoring the @title content – it’s about their users.

      Speaking of tool tips (and other ‘mouse-over’ data exposure tricks) – don’t do it: screen readers don’t use pointing devices like a mouse (and neither do touch-interface users).

      Dude, there is a contract between the users, the software developers and the content creators to ensure accessible content: you have to do your part too, because like they say, garbage in = garbage out…

      • Igor

        It doesn’t make sense to read both alt and title attribute if they are completely the same, screen reader should be able to recognize this situation and read it only once.
        I also don’t understand why “ban” all title attributes just because titles on images might be doubled.

        • Stomme poes

          Instead of the software on the client end needing to check if something’s been doubled (though maybe a nice safety feature, and it *does* indeed sound like something stupid machines could do), it would be a gazillion times better if the author (or their software cough-cough-wordpress-joomla-cough) didn’t do it to begin with.

          Also I’d say if you’ve got a really good reason to use a title, then you ought to do the extra work to make it available to keyboard and touch (and whatever else.. Dragon?) too.

          • Igor

            I agree it would be best if the websites didn’t duplicate text in the first place, but most web developers probably don’t know how it turns out for blind users. I didn’t know until I read it here on Silktide’s blog. On the other hand, authors of screen readers surely must know about this problem and could very easily not read duplicate alt/title.

            BTW WordPress doesn’t put anything to alt attribute on it’s own, it must be the website owner :-)

          • Stomme poes

            Re WordPress: this has been fixxed in the newest-newest versions, but old versions would add in titles on links by default (not alts but titles).

            And yes, lots and lots of web devs aren’t aware of titles across many platforms/browsers/etc, but I think the more who learn, the better! AT does already do a lot sometimes trying to fix broken code (so do browsers) but while I think of course they can do better (NVDA is an excellent example because they are open source, free, and update a lot), I can only expect them to do so much.

    • Walt Stover

      The software is already very expensive. I am a JAWS user and would be happy to test any site and I am doing this as a job right now.

  • Ian Simmons

    Thank you for this. It’s the first time I’ve seen someone actually use a screen reader to really know what they are talking about. Googling around, a lot of people I think are just quoting things from w3c or making assumptions. It’s good to hear from someone who actually went to the trouble of testing and experiencing it.

    • silktide

      Thanks Ian, David here. Tbh what I did wasn’t exactly difficult, any sighted user can just stick a blindfold on, and download NVDA for free. It’s not actually the best solution, the best thing you can do to understand accessibility is talk to an *actual* blind person and watch how they use your website. I didn’t have a blind person to hand when I wrote this :-)

  • Jeffrey Isham

    “Accessible” does not equal “for blind people.” You need to consider other disabilities (hearing, learning, etc.). This is where point 6 comes into play. It gives context when you focus or hover over the element, but not for a screen reader. To give context to a “click here” link, that a screen reader will read, a bit of text hidden off-screen will do the trick. Zeldman is not the internet. Smart and very much an expert, but wrong in this case.

    • Stomme poes

      I’d rather everyone has access to context if context is good enough for some users, rather than holding back and only letting those with mice get the benefit. Touch users, keyboarders, we get no love.

      • Jeffrey Isham

        That is a problem with using “click here” as a link description in the first place. Triggering visibility of the text on focus with Javascript is the keyboard solution. Touch is a unique situation, that we are still discovering best practices for. It’s a tricky one.

        • Stomme poes

          The problem is “click here”. I like/need titles on things like icons, and sure I can get something to show up for keyboard with CSS, but it’s a hack-solution dealing with a problem the content-writers and/or graphic designers should have let us deal with correctly in the first place.

          Agreed it’s tricky. It’s like we have to sneak solutions in.

  • Birkir

    Interesting read, agree with most of the article (been a blind screen reader user for years), but of course a lot of responsibility for web accessibility lies both with the assistive technology vendor as well as with the end user (if I could see for a week, I think I would be equally confused with icons, mouse etc.). But my point in posting to this is the one exception about title. Title *must* be present in the head section of a page, because the page tittle iswhat all screen readers read first when the page has loaded. Make it descriptive (ofor istance, if you are loading a page as a result of the user logging in, make the title reflect the fact that the sign in was successful by saying “Welcome, name ofuser”. Otherwise, keep up the good discussions.

    • Stomme poes

      quote: if I could see for a week, I think I would be equally confused with icons, mouse etc.

      Our grandparents and users who test our websites would agree!

  • Tony Olivero

    This was an interesting article, and I think many of your points are valid. Since John F, Birkir and others have beat me to adding their thoughts on a couple of key points, I wanted to touch on the question that, I think, really boils down to “wouldn’t a separate computer/browser designed just for the blind work better”. The simple answer is maybe, the longer answer is something I should perhaps touch on in my own blog. for the purpose of not flooding David’s comment feed we’ll go with something in the middle.

    in a way, using a screen reader as a blind user is akin to an experience designed for blind users. When I read through this web page, things like sidebar, header, and footer don’t necessarily translate into a nonvisual paradime because the way I hear the page is entirely linear. This is partially why landmarks and headings are so essential; they take the place of a sighted user’s ability to skim for content.

    There are several “blind specific” devices on the market. Things like notetakers that provide a Braille/speech version of a PDA. However, these are typically somewhat lesser powered and don’t emmulate mainstream mobile device functionality. They are best for taking notes, keeping an address book, utilizing as a GPS solution; I have never found one that gives me the same experience on the web as I even get with my iPhone.

    I also think that no matter what, we’ll still have to use mainstream devices with screen access solutions like NVDA, JAWS, VoiceOver and the like. I couldn’t do my job if I had to rely on a specific computer just for blind people.
    There are places I can see the use of a separate off-board solution useful. These include kiosks and similar systems. However, for the most part, I believe our best access will always be achieved by having accessibility on the mainstream device.
    Thanks for the post David.

    • Stomme poes

      Interesting comment. Some things that popped into my head:

      1. when separating a (completely) blind person’s experience from “everyone else’s”… this certainly has disadvantages. People just want to do the same stuff: read news, chat with friends on social crap, email, do work… you know all about that. So in the instances where you say a separate experience would be better, I assume it’s because an even-accessibly-made experience is still sucking mightily. Also, the partially blind and low-vision… which one do they get? Or take? And what happens when a fully-blind and a well-enough sighted are sharing an internet/computer experience together?

      2. adding to #1, if it means twice the work for developers, they’re even less likely to do it (not an excuse, but always the reason it seems). Why Inclusive Design is appealing (maybe falsely at times…). Sometimes a bit harder, but usually a lot less work than several separate methods of delivery.

      3. Maybe the first two points are a dream. Definitely the kiosk thing: our public transport ticket system has been touchscreen since forever, and recently my country has gotten a whole new system involving a transit card. Nothing really improved as far as kiosks went. But, is this because there’s no better solution to kiosks, or is it because the makers of these systems never made a good attempt at meeting the needs of the blind? The darn things sit outside over here and when the sun hits them right, or if bored kids scratch the hell out of the screens… they’re useless for everyone then. I want to blame poor planning first.

      • gordondev

        I think having viable optimized options for people with various disabilities could (theoretically) be a good thing, at least at the environment level. After all, if you spend a lot of time on a computer, you’re spending all of it in your OS, even if it’s just to open your web browser. Why not have your computer work for you, instead of fighting against it? Even non-disabled people do this on a regular basis (just ask any developer that uses Vim, Emacs, TextMate, or any other advance text editor; or any power user of any operating system).

        On an OS level, I think this is where Linux can help (due to its desktop environment modularity). There’s enough compatibility that most applications can either run natively (Chrome, Firefox, etc), with a minimal amount of help (Quicken, Photoshop, etc), or have a native counterpart (MS Office -> Open Office) on a standard Linux distribution, making work for developers rather negligible, but can provide a platform to develop a specific interface for (much like there are applications built specifically for Gnome and ones built specifically for KDE and so on).

        From there, the desktop environment as a whole could be optimized for visually impaired or totally blind users – nixing things like popup notifications and heavy visuals designs in favor of a streamlined, screen-reader-friendly environment.

        Linux also allows multiple desktop environments to run on the same machine, and each user can use their own environment. This would allow the visually impaired user to use the environment optimized for them, while the sighted user can use a standard environment, such as Gnome or KDE. This also means existing hardware can be used, lowering the financial barrier to entry.

    • Sue Basko

      Please see my comment elsewhere on this page. There are some people totally without vision, but many more with some sort of impaired vision. There are really simple, free things that can be done to make a site so they can use it. When your vision is impaired, it is very difficult to learn — or even find — any of these fancy “solutions.” However, if a website is not screwed up with scrolling sections or frames of animations or things that load or pop-ups, and it it has a white background and dark letters, it is pretty usable.

  • Igor

    “7. Autofocus is annoying”
    Would you say it’s annoying on contact pages where I would put autofocus on first input box?
    I mean, to me it seams like a natural thing to do, screen reader would skip all header stuff and navigation, user would instantly be able to type message and send. I’m assuming here that they came on the contact page to send a message.

    • Stomme poes

      It’s the “when it’s my first time on the page” problem.

      Sure, if it’s your 100th time going to “”, you’ll probably want autofocus. But going to a page you’ve not been to before? How about a page where you do know there are instructions and important info before the form? Now you have to backtrack.

      Autofocus would be great if it did what the Browser Vendors claim it will do: that users will be able to choose whether to let it work on pages or not. As a user, if I know I’m repeatedly returning to a page where I know I want to start filling in a form (say, the start page of any social media anything where I already have an account, or most search engines), then I could theoretically in my browser let that go on. So far as I know, no browser has implemented this (yet), but in the mailing lists it seemed clear they meant it to be user-controlled.

      I suppose it would be like, what if you clicked a link someone sent you and you were autofocussed on some input in the “comments” section, so your browser was scrolled down, meaning you have to scroll back up to read the actual blog post your friend meant for you to read? Thank might be a decent example.

      • Igor

        OK, understood.

  • Sue Basko

    When I was in graduate school, I suddenly lost my usable vision, for real. I was without usable vision for 3 – 6 months and was also in excruciating pain. It was a frightening situation of almost being hit by cars, banging into glass walls, and buying strange items at the grocery because I could not see the labels. Because it happened so suddenly, I had no preparation time to learn how to use things such as a reader. Today I have good vision. My experience taught me a lot.

    MANY people are not “Blind,” but are “visually impaired,” which means they see something. The MAIN problem for many of them is screen glare. The MAIN things any web designers can do are: 1) The background of sections with words must be white and the lettering must be black or dark. 2) Never use pop-up boxes or scrolling sections or anything that pops up temporarily. EVerything should be solid and permanent and flat. Use of these other things makes a website almost impossible and totally exhausting for the visually impaired. 3) Use lettering that is pretty good-sized. 4) Make all buttons visible. Do not have any buttons that only show when the cursor goes over them. 5) Everything should be obvious and high contrast. Buttons that do things should look like a button and have a label on them that says what they do. 6) It should be extremely obvious how the website works, as if it is designed for someone that can barely see. 7) The Comic Sans font in 16 point was the only font that really worked for me then. It is thick and has no extra curlicues. I have heard that it works for others with a visual impairment. You might want to have it as an option on any site. 8) Readers or talking things go way too slow to be usable. If a person truly needs that and has no other way, okay. But if not, they are way too slow and it is much better to work to make the visual design as simple and clear as possible.

    • Stomme poes

      Black on white, and high contrast, while helping some visually impaired, can wreak havoc on other users, such as those with dyslexia. Instead, users should be able to set their browsers in such a way that all/most sites work best for them (you can even force all sites to display as 16px Comic Sans, without making everyone else get headaches). No two people are necessarily alike.

    • annag

      Readers can be set to go at different speeds. Yes, there’s a learning curve, but it’s definitely possible to listen quickly.

    • klovering

      I had to giggle a bit at the Comic Sans mention. I find it’s the most picked on font yet has been proven to be the best font for anyone with vision issues and is moderately to severely dyslexic.

  • Alan Brown

    Wouldn’t it be great if data about how sighted users access content could somehow be used to structure how blind users experience a web site.

  • rob

    Great post – that title tag thing is interesting – did zeldman say its an unimportant tag for just accessibility or for everything?

    • silktide

      I assume unimportant for accessibility. It can still be used as a quick and easy tooltip for sighted desktop users. But remember that it only gets shown to sighted desktop users so therefore isn’t a place for essential information.

  • jenn

    Thanks for taking the time to write about this.

    As a person with low vision, I used my browser to zoom in on this page. The contents of the page zoomed in and in the process the left margin narrowed with the result being the the little social media buttons moved over the text and got in the way.

    • silktide

      Thanks for the feedback!

  • Wouter

    I think the lack of structure on popular websites is on purpose; content is drowned in a sea of links and banners in an attempt to keep the user engaged on the site for as long as possible and hopefully clicking on some links that will bring in money.

    If popular mainstream websites would have a clear structure separating the actual content from the fat, it would enable (all) visitors to bypass the website’s monetisation and engagement strategies.

    In a way, your article shows that we are all overloaded by excessive information and commercial crap, and that – sadly enough – it’s just harder for blind people to cut through the mess to the actual content.

    • silktide

      You’re right. Although do you think that hiding all this excessive information and commercial crap to blind people to give them a better experience is a bad thing? Of course we want to make navigation better for them, but it seems if we do that we’ll be giving them a different experience – and ethically we should give them an equal experience. What do you think is best?

  • Paul J Adam

    There’s nothing really “wrong” with using the title attribute, but don’t duplicate the link text in the title attribute. The title should provide additional, useful information if used. Titles will not work in mobile devices though for sighted users, however, they will work with VoiceOver. On OS X VoiceOver reads the title attribute with an adjustable delay that is a bit long by default or the user can press VO+SHIFT+H to manually read it but they will not know of its presence unless they wait for the delay and hear it or manually activate it. VO calls it the Help Tag. On VO iOS the help tag (title) is spoken much faster than on OS X with no ability to manually activate it.

    The thing that everyone forgets about title attributes is that for Low Vision, mouse users who are zoomed in at extremely high levels the title attribute appears as a tool tip when they mouseover the HTML elements with a title. So a large graphic or UI element may be cut off from view but the title would appear and explain what they’re looking at.

    The best accessibility criticism with title is that it does not work with the keyboard only or mobile devices. The browser developers could fix this though!

    • Steve Faulkner

      have to disagree, there are a lot of reasons why use of the title attribute as implemented is an anti-pattern and should be avoided, just because it works with VoiceOver is not a good to advocate its use.

      • silktide

        I can see the debate both ways on this. Paul, you say the title tag has a practical use in VoiceOver (actually I did not know this), but this means its use might be prolonged. Whereas Steve, you seem to be of the opinion it should never be used ever. Unless the entire community agrees on which way is best, we could end up with this split in opinion for years!

        • Steve Faulkner

          I am not saying it should never be used, I am saying it should be used sparingly and only in particular contexts, given implementation and support realities. HTML features are of limited usefulness unless they are device independent and interoperably supported, the title attribute is not, even though it has been in HTML for 15+ years

        • Steve Faulkner

          a topical tweet from today “Will people PLEASE stop using the title attribute? You’re ruining it for us keyboard users!!! Use good anchor text instead.”

          • silktide

            Thanks for pointing that out, I’ve contacted the tweeter to clarify his hatred of title attribute is the same as I described in this article, so our future boycot of the attribute is justified! :-D

    • Oliver Keim

      Thanks Paul, I fully agree. The point that some screen readers have issues should not disallow the use the title attribute for the purpose of our own design approaches. We use titles for explanations of toolbar icons, plus giving hints on how to use them by using hotkeys.

      Reading title attributes also works with Firefox19 and NVDA2012.2 and IE10 and Narrator8 (you need to tab to get the title). Jaws11 had better support but it decreased with version 12. I do not understand why some screen reader producers ignore the need to announce title content, content which is exactly designed to provide better explanations. The design of tool tips was also part of the Windows Styleguides, and others. Why then ignore it?

  • Nic Steenhout

    Quite interesting blog and findings. This reminded me to write something about the potentially negative impact of disability simulation. It’s on

    • silktide

      Thank Nic for the blog response! I do understand your concern that testing in the way I did can lead to false assumptions, but I still believe that some experience is better than no experience so do still recommend other web developers try what I did, although keeping in mind it’s not a true simulation. I do believe the best way to investigate how blind people use websites is to ask them, and wherever possible sit with them as they do.

      Unfortunately though that’s not practical for many companies who might deem this expensive or just difficult. I personally don’t know any blind people I can sit with, which is why I did the testing myself.

      You’re right though when you mentioned that disabled people should educate people about life with a disability. This helps a lot, and in my years of being a web developer I have to admit I’ve barely read any articles about accessibility written by disabled people. I would love to read more about how disabled people use to use the internet (instead of how we think they do), but they seem to be under represented. At least that’s in my experience. I know that many disabled people do speak out about accessibility, but it doesn’t seem to be reaching the correct circles, leaving the average web developer ignorant of accessibility issues, or at the very least unclear on accessibility best practices.

  • Joris

    When teaching my web development students about accessibility there’s nothing better to do than bring in somebody who knows what it’s like to experience blind surfing or working every day. We’re lucky enough in school to count on such an expert and for students, it’s a real eye-opener, even after all the hours of writing good code because we tell them so.

    Thanks for this write-up, I’ll share it with my students right away!

    • silktide

      “eye-opener” – bad pun!
      I absolutely think talking with a real blind user is best

  • ale5000

    Can someone please point me to a page with a complete explanation of all values of role attribute?

    • Brenda Campbell

      Mike Paciello wrote an excellent article explaining ARIA which includes a list of roles :

      • Brenda Campbell

        Sorry, its actually Steve Faulkner who penned this …

        • ale5000

          Thanks for the link but there are still unclear things.
          The role=”banner” make me think of things like google ads but reading the description seems related to site specific title/banner that I don’t have.
          If I undesrtand correctly page specific title inside h1 should be inside role=”main”.
          Is it true?

          1) What role should be a toolbar at the top of the page with things unrelated to the content of the site like google pagerank, time, etc.?
          2) And what role should be the google ads?
          3) And also what about things in the footer like Opera link, like buttons, etc, that are unrelated to the content of the site?
          4) In the frameset pages does it make sense to mark the frame element used to show the content as main and the frame element used to show the menu as navigation also if they are only references of the files and the content itself is in different files?

          • David Ball

            Hi ale5000 in response to your questions: (remember these are my opinion only, you might want to do your own further research):

            1) I don’t think there’s a specific ARIA role for these things, but if they’re at the top of your page you could put them in the HTML5 element which acts as a landmark, mostly the same as an ARIA role. Although why do you have the time displayed on a website? Most people have a clock on their computer so this is redundant!

            2) There’s no role specifically for ads, and you probably don’t want one as this might make it too easy for browser plugins to hide them so you won’t get any revenue! If the ads are in a sidecol, the most relevant container I can think of is , or use the ARIA role “complementary”.

            3) You could use the HTML5 element , and again the role=”complementary” because this isn’t essential information.

            4) Simple answer = Don’t use frames, it’s not 1995 anymore! Honestly I haven’t tested how screenreaders tackle sites with frames, but I can’t imagine it’ll provide a good experience! If you need to use frames for some legitimate reason then I’d recommend testing it thoroughly in a screenreader (you can download NVDA for free) to make sure it works ok. For your navigation use role=”navigation”

            These are only my opinions though, has anyone else reading this got better suggestions?

          • ale5000

            @David Ball, Brenda Campbell: Thanks for the reply.

            @David Ball:
            My site is mainly for fun because I like to code in html, css, javascript and php.
            It is in HTML 4.01 Frameset + HTML 4.01 Strict, some page are still HTML 4.01 Transitional (all pages passes validation).
            It works fine in good browsers but also in bad browsers like IE 6.0 (mostly works also in IE 5.5, I know noone beside me care :D) and I have also tested it in the default symbian browser.
            I want to add some accessibility without change HTML version but I want to keep 100% compatibility with all bad browsers that I know.

            1) There isn’t any particular reason, I just like it.

            2) I clearly separate ads from content, I don’t like to trick the user (like most sites) into thinking that links are in the site itself.
            If the user don’t like ads and he/she is expert, he/she can always find a way to hide it, so why care?
            The revenues are almost ridiculous anyway.
            If someone use a screen reader I think that may get confused by ads (maybe thinking that they are link in the site itself).

            3) For role complementary it say:
            “The content should be relevant to the main content; if it is completely separable, a more general role should be used instead”
            I wonder what is this “more general role”.

            4) I know but I like frames (I use a lot of javascript to fix frames behaviour in various cirtumstances and to reinsert automatically pages in frames when they are outside), there is also a “sort of” noframe version (just a behaviour changed with javascript when there is “?noframe=1″ ) for compatibility with older browsers.
            I just wonder if the role attribute can be used also in the main page of the frameset or not (I have already the title attribute in the frame elements but role is also “machine readable” where title is only “human readable”).

            I know I have to test screen readers but I have had no time yet.

          • ale5000

            There is an article about role that is complete and updated with the latest changes in the specs?
            The previous link didn’t contain role=”article”, role=”listitem”, etc.

          • Brenda Campbell


            1) To confirn, role=”banner” represents the landmark for the name of your site. Role=”main” is usually placed on the containing div for content. To answer your question, yes, H1 tag would be an element of this containing div.

            2) It is my understanding that external items such as google ads and things unrelated to a site do not have landmark associations. I don’t think it is even possible in some instances. Maybe someone else can speak to this point.

            3) For items in a footer that inrelated to a site, you could use role=”complimentary” as David suggested or perhaps role=”contentinfo” which are both used as navigational landmarks.

            4) I concur with David in strongly discouraging the use of framesets (in lieu of CSS divisions), as they can be barriers to accessibility. In addition, frames have become obsolete in HTML5. In frames you have the attribute ‘title’ and ‘name’ which label the frame so that screen readers can associate which content they are reading. If you must use frames and to answer your question, yes, absolutely it makes sense to provide meaningful title/name attributes to ensure that your frame content is interpreted properly by AT.

  • Pingback: SeroTalk Podcast 137: Contacts All Over the Place | SeroTalk

  • Pingback: The H-Blog» Blog Archive » Using Audio & Text to Speech

  • Pingback: A Smattering of Selenium #139 « Official Selenium Blog

  • Pingback: A week of visiting websites pretending to be blind : Post Status

  • hire ipad developer

    Seems to be strange but looking somewhat researcher like studying the things. Here its good sign to judge the screen without eye and get working with it.

  • trisa

    well i want to be really blind well i am sort of because i have bad vision like at the store one time i saw black then i told my mom the my vision was back

  • trisa

    like the black when you close your eyes black but my eyes where open my mom was worried too :3

  • PSD to HTML

    I just came on your blog and read the title of your blog and i thought that, Today i’ll get too much interesting here and I got it after reading your whole post. Such a wonderful post. Hat’s off to your writing.

  • erpi

    I’m surprised that no one here mentions that most blind people that are proficient at using the computer do so using a braille display. I’ve seen one in action and if they want to, they can type faster on it than I can on a keyboard. This replaces the keyboard, mouse and screen but costs anywhere from 5.000 to 10.000 dollars.

  • Sury

    I like your article, I suggest to change ” alt tags” in the second paragraph. It should read “alt attribute”

  • Luiz Felipe

    “No! Do not use” so called expert, I hate these people. Why text readers cant read title attribute if normal users can see it. This is fucking stupid. Why is more important than the answer.

  • NattyDread

    I am creating a website for learning and am in the process of writing ALT text for screen readers to support visually impaired children. Do i have to write numbers in their word form? e.g. 100 as one hundred – or will JAWS read 100 as just that and not 1-0-0. Thanks for any help you can offer.

    • silktide

      I just tested this for you NattyDread! JAWS and NVDA both read 100 as “one hundred”.

      • nattydread

        Thanks David ! That was really kind and helpful of you.

  • Jouie

    I am blind myself and I learned a lot from this article. Like came from a real blind person.

    This post thought me a lot like points number 6 and 7. I didn’t know before that most of the links on the internet have text atribute or whatever it’s called. Also, I now know that the javascript is the reason for the autofocus issue I experience on some of the websites I visit.

    I have a blog about website accessibility and other things. I implement aria and HTML5 there for accessibility purposes.

    Thanks for this post about screen readers.

    • David Ball

      Thanks for commenting Jouie!

  • mfunk

    How about you redo your math?