Part of a Whole

My name is Nicolas Steenhout.
I speak, train, and consult about inclusion, accessibility and disability.

Should Sighted Developers Use Screenreaders To Test Accessibility?

There is some controversy about the idea of sighted web designers and developers using screenreading software to test web sites for accessibility. Some people suggest one must use a screenreader to test their sites. Others believe it is counter productive. I think that very few sighted people can get the correct results by using screenreaders to test a website. I further think that too many people think that the accessibility testing is complete once they’ve used a screenreader on their website.

Different Ways to See Content

A major problem is that sighted visitors and blind visitors experience web pages quite differently. A sighted user tends to scan the content on the page "at a glance" – Our gaze can jump from right to left, top to bottom, and back. Someone relying on screendreading software gets to see the information in the order it appears on a page – They see the information in a "top-down" fashion.

Adept screenreader users can usualy skip from heading to heading (if headings are used on the page), or go from link to link. Yet it is still a very linear way to look at the content.

Different Ways to Use Screenreaders

Robyn Hunt tweeted:

But sighted ppl will not use screen readers in same way as blind, if u c what I mean.

Screenreaders are very complex applications. Habitual users of screenreader have keyboard shortcuts memorised, and can switch between different modes (where the behaviour of keyboard shortcuts is different depending on the mode).

It would be difficult to become adept at using screenreading software unless it is used often. I am aware of at least one course on web accessibility that requires its students to become "proficient" in the use of screenreader for testing. But proficiency doesn’t really compare to the skills developed by someone using screenreading software daily. And these kind of skills must be maintained.

I used to be proficient in the use of JAWS – I had to learn because some of my staff were using it and didn’t have monitors plugged in to their computers. But even when I used JAWS regularly, I wouldn’t have thought of using it for testing.

Comparison With Wheelchair Use

I like to compare the occasional use of screenreading software to test website to the occasional use of a manual wheelchair to test physical structures’ accessibility. Someone who doesn’t use a wheelchair daily doesn’t have basic skills that permit fluent use of the chair. For example, "popping a wheelie" allows getting up and down small changes of level. If you don’t have that skill, you’re likely to think that something perfectly accessible, isn’t. Someone just trying a wheelchair once in a while also doesn’t have the shoulder, arm and wrist muscles developped in a similar way to a wheelchair user’s arms. Pushing a wheelchair is harder if you don’t have those muscles.

In fact, there are studies that show that sitting people in wheelchairs to create "disability awareness" actually causes a negative perception of the situation – people only see the negative without realising the positives.

Incomplete or Innacurate Results

If you don’t develop and maintain the skills required to use screenreading software you may find web accessibility issues where there aren’t, and miss those issues that *are* present. This is more problematic than not using screenreading software to test.

Accessibility Is Not Just About Blindness

A site could be fully accessible to a screenreader user, yet not at all accessible to other people. I wrote Accessibility Is Not Just For Screenreader Users a couple years ago. You may wish to read it to get an idea of other conditions that affect access on the web.

I am concerned that the push for developers to use screenreader to test website is shoving other needs aside. Developers think that their responsibility to accessibility begins, and ends, with making sure their sites work well in screenreading software. But that is not the case at all. If we are concerned about accessibility, and we should be concerned, we must bear in mind all the various barriers our designs can cause.

So, How Should We Test?

There are many tools out there that allows a developer to test sites. I don’t use screenreading software when I test a site for accessibility. I am not proficient in the use of screenreader, and wouldn’t use such software often enough to remain proficient were I to use it occasionaly. So I use my browser, I look at the source code of pages, and I rely on WCAG (even though it’s imperfect).

I also use Lynx, a text-only browser, to test pages. If the content is accessible in Lynx, it is most likely to be accessible through screenreading software. That said, there may be issues where the screenreader interacts with visual browsers and interprets CSS commands such as display:none; correctly.

Beware Your Tools – No Single Tool Is Perfect

Just like Lynx alone cannot determine how accessible a website is, screenreader software cannot determine how accessible a site is. Each tool or method of testing gives a different view of the barriers encountered on a site.

So, if you opt to use a screenreader application to test your site, be prepared to:

  1. Learn to use the application properly,
  2. Maintain your skills with the application,
  3. Remember you may encounter false-positives,
  4. Remember that accessibility is not just about screenreader users,
  5. Screenreading software is only one of many tools that can be used to test for accessibility.

What Do You Think?

What do you think of this? Are you a developer who uses screenreader software to test? Or do you prefer to avoid using screenreaders?

[Edit] Note: Please let me clarify that I am NOT suggesting that sighted developers should not conduct accessibility testing! Of course accessibility testing should be conducted – that is a given as far as I’m concerned. I just don’t think sighted developers can develop and maintain sufficient proficiency to effectively and efficiently do accessibility testing with screenreaders.

Reference to disability awareness study: French, Sally(1992) ‘Simulation Exercises in Disability Awareness Training: A Critique’, Disability & Society, 7: 3, 257 — 266

34 thoughts on “Should Sighted Developers Use Screenreaders To Test Accessibility?

  1. Well put! “Good design is about understanding user requirements, if you aren’t sure then user test, but if you pretend to be a screen reader user, you’ll get pretend results.”
    I saw this quote by Hugh Huddy from RNIB a while ago. I can’t find the source page anymore, so I’m glad I’ve kept a record of it.

    I use screen readers for very basic testing and I also use Fangs screen reader emulator but I would never claim that something is accessible (or not) to screen reader users based on those tests. The best solution is to test with real people because, even if we get all the relevant WCAG checkpoints ticked, there is no way to tell if the page is also usable.

  2. Hi, I absolutely think that testing the site and/or software application you’ve developed with screen readers, screen magnification tools, and other adaptive software is crucial to providing good access. I’m not a developer, but I am a daily screen reader user. I think that a developer can test his/her code if they get a basic knowledge of how to use the adaptive software ( they don’t have to know it inside and out), in order to test their site, or software. What a developer of a site or a software application could do to Thoroughly test their code as far as accessibility is concerned, is to get people with disabilities to test their code. That way testers who are using these assistive technologies to their full potential, can subsequently provide useful feedback to the developer. Also, In the case of software in particular, i feel that , providing betas that are redally available is crucial in accessibility testing.

  3. @Iza, I think you got it – it’s fine, and perhaps even good, to give it a quick whirl to get an idea, but to get true results, you must “farm out” the testing to people who are intimately familiar with the adaptive software.

    @Dan, the problem is that if you don’t use screenreaders regularly, you can really mess up and get the wrong impression. I do agree that it’s better if a site is put through all its paces, including user testing. Unfortunately, such user testing costs a lot of money, and we’re already seeing too many developers who say they aren’t “against making accessible websites”. These same people say it’s too expensive to build accessible websites – they are unlikely to be willing to spend extra money on user testing. It is unfortunate. I do agree with you that providing beta versions of application for users to test is a very effective way to achieve the goals.

  4. One other issue for sited web developers to keep in mind is that if a screen reader cannot see their content, a search engine indexing bot can’t either. For example, if you have a series of graphical links on your page, and no alt tags for the graphics, Google’s web crawler does not know how to index the link. Let’s not forget that putting that W3C tag at the head of the page does not automatically make a page accessible. It only tells the W3C testing tools that the page exists. The page to go to to know if your page is actually W3C compliant or not is: That validation tool is not the end all and be all for accessibility but it is a good testing tool to pass.

  5. I’m using NVDA to test ARIA features that are impossible to detect without a screenreader. Particularly to ensure the features are working, for example a role=tab only gets read when it’s the immediate child of role=tablist, otherwise the nodes in-between need a role=presentation. The only way to test it is with a screenreader. Otherwise I acknowledge that I use a screenreader differently than a blind user and that accessibility is not just about blind people. That said I strongly encourage to test with a screenreader. After that, if you have the opportunity to do it, get feedback from real people with disabilities because diversity provides manifold perspectives.

  6. Well said Nic, and thanks for quoting my tweet. That was exactly what I meant. Also people often forget that there are people with partial sight with very different accessibility issues. Not to mention all the others…

  7. I am a developer who makes web based elearning resources.

    With my admittedly limited expertise in this area, I am afraid that the message I am getting is that accessibility testing is starting to head into the “too hard or expensive” basket.

    I do try and there are in-house standards to make sure we adhere to most WCAG1.0 standards but testing would be beyond our in-house expertise or budget.

    I wish this wasn’t the case.

  8. This is analogous to usability testing. The developers and product managers need to do their own testing to determine whether they think it is usable bu that is no substitute for usability testing with users outside of development. At Deque we do both. Our developers use NVDA and JAWS while developing and then we have a non-sighted person outside of our development group to test the usability of it from an external-to-development perspective.

  9. I hate to say it, but I tend to disagree with you on this one. I believe testing with at least two different screen readers is crucial to ensure accessibility. VoiceOver is an obvious choice for me because I’m mostly using Macs. Window-Eyes could also be a good option, but the slacker in me rarely goes that far. Second one usually is NVDA on Windows virtualization. I tend to stay away from Jaws because of their abusive licence policy, but some of my colleagues have full versions and I rely on them for feedback.

    Indeed, accessibility is not only about providing accommodations to blind users, but screen reader testing is still the best option out there to intercept problems that cannot be identified otherwise. Of course, the real way to make a website accessible is to follow the guidelines, run the appropriate tests to endure each of these guidelines are applied properly, but even when everything’s done according to the specs, some usability problems may occur that only a screen reader can point out. I’m won’t pretend we can understand what it is to use a screen reader as a blind user, but we can at least use it to help us put ourseleves in that another perspective. And let’s not forget blind users aren’t the only ones relyng on screen readers. Sighted people with cognitive disabilities might also find them very useful.

    So, let’s consider the following two examples:

    Say we have an image as the first object in a paragraph of text. The image has it’s alt, the alt describes the image pefectly so no problem there. Because the image is contained in the same paragraph as the text, the screen reader wil not make a short pause after reading the alt – it will follow up directly with the text contained in the paragraph and read the whole thing as one long string of text. This could possibily create confusion or uneasiness for the user, as the value of the alt might possibly conflict with the general idea of the paragraph. According to WCAG, everything would be peachy, but while testing with the screen reader, we’d notice the discomfort and we would be tempted to add a period at the end of the alt value to force the screen reader to make that pause s it’s removes that potential uneasiness. Something we never would have catched without a screen reader and that can definitely help the user.

    Also, let’s say we have a navigation menu containing the following item (non-french speaking people, please bear with me, as I could not find a good example in english – feel free to suggest one if you can think of one though): “Logos et normes”, which translates to “logos and standards”. When a screen reader reads “logo et normes” , some users will understand it as such, but others might understand it as “logos énormes” which actually means “really big logos”. Without a screen reader to make us hear the list item, we would not flag the potential confusion as there’s nothing in the WCAG that actually applies to this situation. While having it read to us, it becomes clear there’s a problem and we would therefore consider changing “logos et normes” to maybe “normes et logos” or whatever to avoid this potential confusion for some users. Again, something we never would have catched without a screen reader and that can definitely help the user.

    I’m sure we could come up with other examples as well. So I do think testing with a screen reader is a very important part of the process. Only testing with a screen reader is clearly not enough, but in my opinion, a thorough accessibilty audit cannot exclude using a creen reader to test things out.

    There’s what I call “technical testing” which means going through our checklists and making sure all requirements were applied properly to our content/code/page, but there’s also “functional testing”, which means going over the whole thing from a higher perspective to catch any other problems that may sit between guidelines but still cause problems for some users. In a way, it’s usability principles applied to accessibility, but at the end of day, it’s making sure our content is accessible to all as well.

  10. I think using screenreaders to test is essential. Before ARIA and NVDA, I didn’t know how to ensure my pages were accessible. The only tool we really had, was turning off script, and making sure the page displayed.

    First time NVDA read out an update in a live region, I was sold on the use of ARIA. And NVDA as a test tool.

    What we need are training tools for the sighted in how to effectively use these tools for testing.

    I’m not going to buy the “it’s hard” as an excuse, either. We manage with our other tools, including editors, conformance checkers, and testing tools. If we can figure out how to use Eclipse, we can figure out how to use NVDA.

    The use of a screenreader like NVDA should be part of the web page development and design workflow.

  11. I’d push back on the wheelchair analogy — sure, someone not used to driving a wheelchair will over-estimate accessibility problems, but is that a bad thing? What if there’s an older person who similarly lacks arm strength to fully exercise their chair, or a person who finds themselves in a wheelchair temporarily? Leveling off small bumps might be quite helpful.

    Same argument would apply to web accessibility — wouldn’t it be great if an inexperienced screen reader could access your page in an efficient and usable way? Maybe our tools just aren’t good enough yet to make the feasible, but we should keep challenging these assumptions!

  12. Although I agree that testing with a screen reader will never totally simulate the user experience, I do think it is a useful experience. I am a big fan of involving users and I also think that whenever possible, they should be remunerated.

    I also agree that many people forget that accessibility is not just about screen readers and visual impairments.

    And finally, as I said on twitter last night, I think the analogy regarding wheelchairs needs to be nuanced. People using power (motorised) wheelchairs will usually encounter more severe problems with regards to the built environment and many do not use their mobility aids in the same way as people with manual chairs. In short, the disability community is very diverse.

    Thanks for the article, it is a good point of discussion.

    Cheers !

  13. This is definitely a thought provoking article. Thanks for putting it out there.

    I’ve been working a lot on improving the accessibility of ‘s next version. We’ve made lots of good solid advances in accessibility of this platform, and many of them were made by people like myself with no physical disabilities.

    When I’m doing accessibility work I rely heavily on automated testing tools like to do most of the heavy lifting when it comes to finding problems. There are obvious limitations to this and certainly it is nothing like asking someone who is a keyboard only or screenreader only user to review the site.

    I don’t do much testing personally in anything but VoiceOver, and I use that occasionally because it is easy for me to use. For Windows users NVDA would be a great choice to get a sense of how a sight would work (or not) through a screen reader.

    I do think that it is important for developers to have this sense of how screenreaders work because otherwise it’s very difficult to even begin to put yourself in someone else’s shoes. Ultimately, for able bodies people working in the field of accessibility that level of basic understanding is key. There are always going to be people who tend to oversimplify things.

    As far as your analogy with someone who occasionally uses a wheelchair, I spent a week in a wheelchair one year in university as a personal challenge. It forever changed how I understand accessibility issues. I do have a few stories from that time that still resonate.

    Metaphors are easy to pick apart, but it is important that not everyone who uses a wheelchair on a daily basis is always able to pop a wheelie. Just because a floor of an office building has a ramp doesn’t mean it’s perfectly accessible, it just means it is probably accessible enough for most of your users most of the time.

    I’d encourage folks working on accessibility to try their sites with as much AT as they can get their hands on, but to not rely on the results of that process to tell them anything definitive about how people who depend on AT will be actually using their site.

  14. All right! Some excellent discussion going – thank you guys & gals :)

    Some excellent points made – and y’all are making me rethink my position on using screenreaders to test. I stand firm with my 5 points to keep in mind if you chose to do testing with screenreading software though :D

    @Catroy – yes, every disability is different. You’re right that a power wheelchair user encounters barriers where a manual chair user wouldn’t – and vice-versa :)

    @mimi I don’t believe user-testing, whether usability or accessibility, should be unpaid work.

  15. @mimi I understand your position – and I’ve heard similar arguments against accessibility in general, testing specifically – small firms can’t afford to take the time to learn the skills to be able to know what they are doing.

    I’m not disagreeing here, just saying… Cost is a major issue and it can be used to justify lack of action at so many different levels.

  16. Interesting article and discussion.

    I just spoke with a client today who thought a form they created wasn’t accessible with a screen reader, because they didn’t know about Jaws and forms mode. What’s worse, they were still using the mouse to interact with the computer. I think things like this are a real problem. I don’t have a issue with folks testing with a screen reader, if they realize that they will need to put in some effort to really learn how they work. However, I fear that all too many folks are not willing to read the documentation, and just jump right in.

    Unfortunately, screen readers are almost impossible to learn without consulting the docs. I know this from my own experience, as I am a long-time screen reader user (I’m totally blind) and even I can’t pick up a new screen reader and run with it without some preliminary reading.

    I think the argument of this article is valid, that you can’t replace testing by an everyday screen reader user with testing by a casual or “testing only” user. However, if that’s all you can manage, it’s better than nothing.

    As for finding screen reader users to test your site for free, maybe it’s just about asking in the right places. Web-only discussion forums are the wrong place (many blind folk find web forums too inconvenient to use frequently). The right places might be mailing lists and Twitter, if you have the right set of followers.

    Aaron Cannon, Web Accessibility Consultant

  17. Great conversation – Assuming the seeing individual is appropriately trained on how to use a screen reader correctly (like any other tool), including screen reader testing as part of a larger suite (and not the sole method) of accessibility testing activities during the development/QA cycles makes perfect sense to me. This is especially true when it comes to looking at the web 2.0/ria/dynamic content so prevalent these days which may or may not work as expected, even if everything has been done to make it accessible. Martin and Denis make great points re this issue.

    I also agree with a comment above from Shelley that we do need to push out training material to members of the dev community who want to test using a screen reader or other adaptive technologies to avoid false results.

    Does that mean that end-users with disabilities should not be part of user testing? Absolutely not. But the reality is, as Mimi points out, it’s not always as simple as “finding” screen reader or other AT users to test. You also need folks at different screen reader skill levels, because the advanced screen reader user may not identify an issue that the average user might experience.

  18. Great discussion. I’d like to highlight one point in screen reader testing though.

    When testing with a screen reader or any assistive technology, in my opinion, there are two types of testing.

    1. Is the average screen reader user? He/she might not know what is possible or doable or even understand the standards or guidelines. This type of user is important but is not enough.

    2. A screen reader user who functionally and technically understand the standards and guidelines and possibly also unders the development enviroment though might not be a developer themselves.

    I have often found clients misled by only the 1st type of testers. Someone needs to validate the feedback of a user test also!

  19. Nic, thanks for inspiring this great discussion. I agree that accessibility testing needs to be done carefully — perhaps the right word is even “warily.” There are limits to each kind of testing. If you do have a person with disabilities test your site, be sure they are well schooled in not only AT but also usability testing. Otherwise you are likely to learn only what they prefer or what they are used to. Another way to guard against that is to do a conventional usability test with a number of people who have disabilities. Consider what they say, but pay the most attention to what they can and can’t do. At least that’s my take on it.

    And I’d like to encourage Alfred to keep up the conscientious effort. Do what testing you can when you can, but remember that there is no such thing as a perfectly accessible site. Even the folks who wrote WCAG realize that a feature that improves accessibility for one audience might impair it for another. So give it your honest best effort and remain open to making further improvements if anyone lets you know that a feature turned out to be inaccessible to them.

    I can honestly say that having to create accessible content has made me a better Web developer. It’s like building a home: It can be done faster if you cut corners, but if you conform with standards and guidelines you will get better results in the long run.

  20. While following this discussion, it occurred to me that it would be helpful to distinguish between using assistive technologies for testing our websites during their development from using these technologies to evaluate (ours or someone else’s) websites.

    I agree that developers should be encouraged to get a hands-on experience with as many AT devices as possible, and use them for testing. Having that experience helps us all understand and apply the specific accessibility techniques correctly. However, whenever someone asks me to evaluate a site or a page for accessibility, I always say that my evaluation should not be regarded as a replacement for user testing.

    So, how’s this for a wrap up?:

    Website developers are encouraged to use assistive technologies prior to user testing to reduce the number and severity of accessibility errors discovered by users.

  21. “Should Sighted Developers Use Screenreaders To Test Accessibility?”

    Personally, I think this question is overly broad.
    It does not make the distinction between what is programatically exposed to Adaptive Technologies (AT) and what is the effect in a “real world” context.

    I use screen readers to determine if an object or element which is coded according to the appropriate specification, is exposed to the AT that I am testing against.

    The only thing this assures me of is: on this day that code is properly exposed in that version of that AT. That is nothing I would like to hang my hat on.

    It is better to use tools which expose elements and attributes in the Document Object Model (DOM) which are in line with the specification for the page being rendered.
    We have to remember that the screen reader (+ version) we may be using is a software product which may have its own bugs and deficiencies. You cannot reliably code around the behaviour of a single AT.

    I’ve spent years working with developers saying “you can do this because it works with JAWS and Window-Eyes” only to discover in the next version of either, it is broken.

    We also have to consider that we are not full time screen reader users. This falls into the area of ISO 9241-11 which is part of the standard on usability. — “Usability: the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.”

    As sighted developers we cannot meet the requirement to evaluate the functionality in the specified context of use. We are not representative of the user base we are testing against.
    We should only ensure we are coding to the appropriate specification and hold the AT vendors to the same standard.

    Use screen readers to test that elements are exposed? Yes (sanity check).
    Rely on the results? No.

    Until AT vendors are held to the same standard which we all strive to achieve, do your best, validate your code, report the bugs in the AT, and hope for the best.

  22. A very good discussion, and thanks for the article. I think Jeff had a good point – there are many not so proficient screenreader users out there, so conducting Screenreader tests without an expert knowledge of all its commands may identify problems that the skilled screenreader user may pass over.
    We maintain our testing tool ( with the premise that it should be possible to test for accessibility *without* having to conduct additional screenreader tests – we use those tests instead to inform our test step descriptions. But clearly, doing additional screenreader testing can never be wrong if other aspects of accessibility are not forgotten.

  23. Thanks for an excellent and thought provoking article.

    I’m very fortunate to have a blind colleague who carries out all of our screenreader checks, using several applications to do so.

    I’ve tried, on numerous occasions, to do it myself. On each occasion, after comparing results with my colleague, I’ve come to the same decision: Sighted users can’t do effective screenreader testing themselves.

  24. What a developer is expected to do has a lot to do with the size of your shop. If you are a one-person show, you probably need to get some experience using screen readers, or find some friends to help.
    In a large development group, developers may only need to master various software tools to perform unit testing, while a QA or usability testing group would provide the expertise with screen readers, magnifiers, speech recognition, etc.
    For best results, you want to focus on the strengths of your personnel, and having all developers master screen reader use may not be the best use of their time and effort.

  25. @SteveBuell
    [quote]Use screen readers to test that elements are exposed? Yes (sanity check).
    Rely on the results? No.[/quote]

    This is so true, I’ll have no other choice but to tweet it. ;p


    From my perspective, those other aspects of accessibility are the zillion little things that reside outside the boundaries of every WCAG 2.0 success criterias and that one caot spot without using assistive technologies like screen readers, zooming software and the like.

  26. 1) I vote *ANY* tool, including your eyes (which you say you use to review code to insure it’s compliant) is better than NO tool. A screen reader is a valuable tool, no matter your proficiency.

    2) The problem with developers (or QA people) testing their own site is they are intimately familiar with it. “Self-testing” doesn’t dismiss the need for outside testing.

    3) I asked my wife to pull a wheelie in her motorized, electric wheelchair. She couldn’t. We’re contacting the manufacturer – while we are certain it meets “The Standards” it is obviously defective and under-tested.

  27. @Gary, I’m glad I’m not the only one to have reached that conclusion.

    @Terry, your sarcasm is not particularly productive.

  28. Great article and comments! My thought is that if a developer wants to learn how to test with a screen reader, that’s great. It’s required as a part of proper accessibility testing. But, in the real world, frankly, not many developers are going to do that. Many tools out there can substitute fairly well, such as Fangs and Lynx noted above, and to which developers will be more receptive. If the owner of a website is serious about web accessibility, he or she can assign users more familiar with screen readers to test, either in-house or out.

  29. I have heard this argument before, that a sighted person usually won’t be proficient enough with a screen reader and risks getting false negatives or false positives while testing with one. However, I disagree. Blind users have a range of proficiency too. Some sight disabled folks that I have worked with never got beyond the basics of using their screen reader. Thus, I think a designer/developer who knows the issues and achieves some proficiency with a screen reader can use the tool and should use the tool to check their work. Then of course, a screen reader is not the end-all for accessibility testing, it’s only one tool in the testing toolbox.

  30. What a fantastic discussion this post has provided! Don’t you just love the web? :)

    well I have to say, the discussion has really influenced a change of heart in me.

    Most of my work involves user research so it’s been easy for me to believe real users of AT should be The testers. But Denis’ French nav
    eg reminded me the small things we can identify and correct that actually make a big difference. and if you do have the luxury of conducting user research it reduces the number of road blocks giving you more chance to focus on the more obscure things only AT users might find.

  31. @ Terry, great comment to which I whole heartedly agree.

    It’s sad your comments were dismissed as sarcasm.

  32. @Obiki – I was not “dismissing” Terry’s comments as sarcasm – but I do note the tone of his 3rd point to be rather sarcastic – and not productive to the debate.

    I should have specified *manual* wheelchair. I have now edited the post to reflect that. But the point I was making remains valid.

  33. Hi,

    Reading the post, I was first a little upset by the idea that tester would not be able to be as good as blind peoples in using screenreaders and then would not have to use them for testing.

    But, reading further I was happy to discover the long list of comments and the different views that this post permitted to share.

    I totally agree with my colleague Denis Boudreau and I would like to add something.

    At AccessibilitéWeb, we encourage the peoples developing Web interfaces to do it with a screen reader in their ears to have a direct and very short feedback to their work. Exactly in the same way they are checking visually any HTML or CSS modification they do.

Comments are closed.