A - Don’t have any screen readers. I would have to buy the top 3, which is a lot for a lone freelancer

B - I often use these tools, but don’t feel satisfied that they really help the matter as they aren’t human devices.

C - No disabled friends or colleagues! I can do red/green colourblindness testing myself (as I am!), but other than that, I don’t have any contacts.

D - I guess this is the one I go for to be honest. I tend to build with standards, and be aware of ‘best practices’. Rigorous testing is usually outside the boundary of time and budget on the projects I work on.

I simply don’t have the resources to do any extensive testing with screen readers nor do I know anyone, (un)fortunately.

Jon makes a good point. Often clients don’t have the resources either to allow for such testing, so best practices and standards will, hopefully, do the job good enough.

I’d have to admit to just B and D myself. Using lynx makes for a very cheap (free) simulated screenreader. While it certainly doesn’t give you the full experience needed to say “I’ve tested with a screenreader!” it does give you a very good idea of how your site reads in alts and un-styled text.

As a side-note: I’ve recently discovered that browsing through sites with a cell phone makes you really appreciate those skipto links!

As for Opera 8, it just reads out the text on the pages, but as far as I experienced, you have to select the text first and bullet points etc aren’t read out as bulletpoint, so for accessibility testing Fangs extension to firefox would be even better.

I’ve seen it brought up a few times, how many sighted people are going to use a screen reader to the level of a blind person?

If you can’t use it in the same way, you can’t test it properly either.

A: I use IBM Home Page Reader, Jaws and soon Windows Eyes. These are expensive, but fortunately at work they see it as important enough to purchase.

They work very differently though, and support different subsets of HTML, so you can’t try to cater for the main one(s) — this is as bad as trying to develop IE-only web sites, for example!

With a standards compliant page, using semantically meaningful markup though, and with accessibility considerations applied, you can navigate pages reasonably well with these screen readers, I find.

[FANGS, a Firefox extension will show you what JAWS will typically read out. Quite interesting.]

[Opera 8 is limited. It is a text reader, though understands some voice CSS (proprietary, mostly), which is better than what JAWS and the others do! But, you can’t even follow a link with Opera 8’s voice!]

B: IMO, automated accessibility validation tools are almost always useless, because of the human subjectivity required. The most it can tell you is that you might have failed, never that you might have passed…

C: I have not done this, as I don’t have any friends/colleages who are disabled and use screen readers. Can you rely on this? Not alone, I think. I find that people seem to forget that those with disabilities are as unique as anyone else. We all have preferences and opinions, so you can’t just go on the opinion of one or two.

D: I do this the most. Most important, I think, is semantically meaningful (X)HTML because end users can configure and change just about everything else, so this is the one thing developers have full control over. As screen readers etc are so different in their outputs, we can’t (and shouldn’t want to) tailor to the most common one(s), as that defeats the whole ethos of the web standards approach, anyway! Hopefully screen readers will improve, so semantically well marked up HTML will only read better!

That’s not quite accurate - Opera is a voicing/speaking browser, which is quite disctinct from a screenreader - it’s not designed for people who are blind, but more as an aid to navigation for people with motor difficulties, or an aid to comprehension for people cognitive difficulties, that kind of thing.

Opera’s aural CSS support is based on the CSS3 Speech Module [http://www.w3.org/TR/css3-speech/], which is not a recommendation yet, so Opera adds a prefix to the property names (as it should), which is “-xv-”

You can fully navigate with spoken commands - http://help.opera.com/Windows/8.00/en/voice.html - and you can make ALT (or any attribute) text get spoken if you bring it out with generated content:

img:after { content:”(” attr(alt) “)”; }

However since Opera aural styles are part of screen (not aural) media, I don’t how to make the attribute text get read out without it also being visible.

But the real power in this is XHTML+Voice - where you can program the entire interface, recognised grammar - build complete applications that work by voice. I’ve only just begun to play with it really .. but it’s all looking very exciting. More developer info at http://csant.info/vox/

For A, I use the Firefox extensions Fangs, FoxyVoice, and some of the tools of the Web Developer toolbar, Opera’s “user mode” settings, and then just “common sense” testing (i.e., attempt to navigate a page w/o using the mouse). My employer is also in the process of purchasing JAWS.

For B, I rely on “validators” (isn’t “suggestors” a more accurate term?) to provide me w/ a checklist of things to verify and to point out glaring errors where they can detect them. Cynthia Says is the one I use the most because it’s built in to the above-mentioned Web Developer toolbar, but I will consult Bobby at least once in the process. I also run down the W3C Checklist of Checkpoints [1].

I must admit though that like many here, I rely heavily on D, at least the following of best practices. While I would not say we rigorously test (to me that implies you test the site in a plethora of assistive technologies, which we simply don’t have at our disposal), but we do the best we can with what we have to work with.

Notes:
[1] http://www.w3.org/TR/WCAG10/full-checklist.html

B: False
C: False
D: True

B: Tried using these but found that I was faster just reading the code myself after a few days

C: I have done this with colorblind coworkers on a few projects but often lack access to disabled individuals for testing. Is try things like reading the pages without my glasses and putting my mouse away when using a page to simulate some disabilities.

D: Following best practices (writing valid code. picking good color combinations, etc.) should be a given but rigorous testing is often not possible for any number of reasons. My hope is that by thinking about accessibility while building and designing I can at least catch any major problems before they are entrenched as a part of the system.

C-Ask a blind person to test.

There are some things allowed under Section 508 which are not detectable by B, such as D links or captions appearing below a picture.

An example of a page produced using this method:

http://www.sfmuni.com/php/routelist.php

Note the hidden instructions to visitors using screen readers.

B: never.

C: sometimes. Have some blind friends. They use unknown (various) software on top of IE6, and report back if they find any problems.

D: mostly. Trying to find some middle ground where things are working reasonably well.

1) Accessibilities guidelines: I run my pages through Bobby, Cynthia, and Web Exact. Plus manual testing by way of the W3C WAGC, of course.

2) Text browsers: I run those myself using Lynx, the Lynx emulator web utility, and Fangs (Firefox 1.0 plug-in).

3) Text readers: Jaws (having an outsite testing agency perform the testing for me, they report the results and suggested fixes).

4) Mark-up: W3C, Web Exact, and Site Report Card.

5) CSS: W3C.

6) Privacy: Web Exact.

7) SEO and Speed testing (site load): Site Report Card.

8) Browser compatability self-testing: I use IE 5.0, 5.5, 6.0, 6.2 on Windows, 95, 98, 2000, NT, XP, XP2, Netscape 6.2, Firefox 1.0, and Opera 8 Beta (on Win XP2).

9) Browser compatability by others: Safari 1.2.4 and IE 5.2 for Mac.

10) Other devices self-testing: Openwave SDK 6.2.2 (cell phone emulator).

11) Other devices tested by others: Dell Axim MS Pocket PC Windows Mobile 2003 and 2nd edition version 4.21.1088.

12) Resolution testing: 800×600 and 1024×768, plus I use a screen sizing web utility for all other sizes.

13) Style, color, script, and image removal testing: Firefox 1.0 web developer tool kit plug-in.

14) Other: Visitor feedback.

Some of these tools test for more than what I listed (e.g. broken links and what not). None are perfect, but all reveal things when used in this way. And as I said, all this stuff plays a role in accessibilities because it’s not just people with disablities that I want to allow access to, if everyone if possible.

The two best tools for testing multiple things I think is Site Report Card and Web Exact as they both check for so many things.

There are links in the Side-Bar of the “Access” page of my Portfolio site: http://www.green-beast.com for most of the tools and utilities mentioned if anyone’s interested.

Mike

Mike

I’m lucky enough to have a copy of JAWS for something that loosely relates to testing. I realise that my use of JAWS is a world away from that of an experienced user. JAWS is a complex beast that takes time and dedication to learn to use properly.

Cheers
Kevin

b) don’t use bobby and family, same and more issues are found by jaws
We use of course HTML and CSS validators from W3C.

c) I have a network of people using different screenreaders in case I want a check in a specific piece of software; one of this resources is:
http://groups.yahoo.com/group/uvip-web-test/

d) of course one relies on his experience as well
I think we can say to understand the guidelines/best practices.

B] Checking tools and validation tools. I use an arsenal, though often get feedback from others. Bobby, Cynthia Says, Mozilla extensions, w3c validator, css check, delorie web tools, color/contrast checks, … There is no one tool that is an end all check for accessibility. As a matter of fact, sometimes a fix for one group of challenges may place additional challenges on a different group of users. I think we need to be aware of Cause and Effect. Years ago during an online accessibility event, material was delivered in rich captioned multimedia with transcripts available soon after. The transcripts, at that time, were offered up in all caps and it was very difficult to read. I was working with some javascript to transform the transcript content to all lower case which was easier to read than all caps for most people. All caps delivery may affect most users, and especially those with reading or eye tracking issues. So we need to be aware that tests are automated expectations and a wide variety of people or users are more reliable.

C] I do have some disabled friends and others to ask or have check work. I also often try a variety of other things, like mouseless navigation (a key issue for many users, accessibility challenged or not). Sometimes Scripting or CSS can make links or navigation inaccessible. Hidden skip links may not help those that have motor, physical challenges, even when they can see the links on the page. They still have to get to those links, and have a way to activate these.

D] Follow best practises, test in a variety of ways (including keyboard only, etc). Following standards, guidelines, and accessibility recommendations helps.

I am glad you have launched this website, and hope people also start thinking beyond visual challenges and expensive devices. Some important issues can be checked with the equipment we already have. [a keyboard and a mouse or not].

A: Testing with HomePageReader, JAWS, WindowEyes; I’ve installed HAL, but mostly just for kicks (though I’d love to know more about its market penetration).

B: Use HiSoftware’s AccVerify when testing larger groups of files, but knowing full well that I’ll still have to test manually.

C: Yes, we run things by our testers all the time - whether specifically on a contract or just for some of the things we are building ourselves.

D: Using best practices is only part of it - I don’t rigourously test much of what I build now - partly because we just know how things work and will react to various technologies…. There are times when we test much more extensively - usually when working with new strategies or situations.

The BEST way to do it, but hardest is C, by testing it on actual people with disabilities…

B. We use tools like Booby and Cynthia Says mainly as sanity checks. Certainly not as gospel that the page is accessible.

C. A few times we have commissioned accessibility audits of our sites where real users with physical difficulties used our sites but these audits are few and far between.

D. One of our sites was “See it right” approvided by the RNIB and getting feedback from them on our design was interesting. Clearly, we build upon experiences and our own knowledge to build the sites. (Then, along come our Content Editors, some of whom don’t quite understand the issues… :-( )

The thing about testing is it only reveals problems or the lack of them. It doesn’t prove there are no problems, ever. This is especially true in screen readers because of the different versions in use and the immense degree of customisation they allow. Many blind users don’t know how to use them either; they just kind of muddle through.

Forms are the biggest headache; just getting these accessible in JAWS and Window-Eyes on default settings was a hell of a task.

I think every web designer should learn the basics of JAWS and test on default settings. It is a revelation. JAWS has some nifty features the others don’t, so it doesn’t reveal some problems that others do. However, the way it renders is much more typical than HPR.

JAWS has a forty minute trial mode which is enough for most people’s testing.

Press Insert+V with JAWS and turn “Virtual labels” Off. If form elements have not been labeled, you should hear the control identity only (i.e. edit, combo box, checkbox, etc)

If you do not have AT at your disposal, you can manually check the presence of explicit labels with your mouse. Click on the text and the focus should be placed into the form control. Or hover your mouse over the form control and check if the title (tooltip) is present.

I really don’t put much stock into automated tools. I think it is great to identify any images that you may have forgotten to add empy ALT attributes, but beyond that, a good manual inspection with an AT demo is the way to go. In my experience people do not manually check provisions or checkpoints that require a manual inspection, and consider the page/appication to be “accessible”.

Here are some more JAWS tricks (you’re welcome ;-) )

Insert+F7 - Links list. Great way to quickly check the presence of a skip navigational link

insert+F9 - Forms List. Great way to quicly check if frames have been given proper titles.

Insert+control+shift+F1 - lists the HTML elements and attributes in a virtual screen (straight text). I show this keystroke to visually impaired users who are testing with JAWS. It is a great way to get to the tags and attributes without mucking through the source code.

control+alt+arrow keys - table navigation
control+alt+numpad5 - reads cell information