What's the deal with screen readers?

Accessibility
1

I’d like to get a better handle on accessibility, and one facet of doing so (I assume) is to try out some screen readers. I work mainly on a Mac (I have Windows installed on the Mac, and thus use it with a Mac keyboard, which may be a cause of problems in regard to screen reading software).

I’ve tried the Mac VoiceOver program. OMG, what a mess. It has a nice voice sound, but I couldn’t figure out how to navigate a web page with it even with my eyes open, reading the instructions. A lot of them simply don’t work, and they are far from comprehensive. Man, I’d hate to be relying on that thing.

OK, so I try NVDA, a free download for Windows. Maybe it’s because I’m using a Mac keyboard, but I couldn’t get it do do anything! The damned program just kept screaming at me and repeating everything I was doing (like an annoying kid) as I tried to get it to read out a web page. In the end, in panic, I just uninstalled it, because I couldn’t do anything in Windows without it following me around. (Perhaps it was the keyboard at fault, as I couldn’t find equivalent keys to the Windows ones that are meant to turn it off and control it.)

OK, maybe JAWS is the deal. But OMG :eek: $1000 bucks! I don’t want to pay that just to test out accessibility.

So, my question: are screen readers really so hard to use and/or test, or am I missing something? I’d like to do the right thing and understand accessibility issues from this point of view, but there seems little incentive to bother. Is it that screen reading software a bit like CSS of the 1990s—just not properly developed/supported yet? I wouldn’t have thought so. I would expect that VoiceOver for Mac would be a good way to test the accessibility of a web page, but how anyone could learn to use it is beyond me. If I had to use it with my eyes closed, I’d surely go bonkers in no time. The tips on how to use it are hopeless. I even went to a few tutorials online and followed them to the letter, and got absolutely nowhere.

Does anyone have any thoughts to share on how they approach screen readers? Stomme poes has mentioned them in this thread post 89f: http://www.sitepoint.com/forums/showthread.php?t=708177) but I thought it best to start a fresh thread on the topic.

2

OK, maybe JAWS is the deal. But OMG $1000 bucks! I don’t want to pay that just to test out accessibility.

Yeah. Big turn off.

And it gets better: there’s a 40 minute demo you can download, but Freedom Scientific has it in their not-so-fine-print that it’s NOT for developers to use! But, it is still there of course.

If I want Dutch voices, though, I’ve got to buy it.

Anyway, your keyboard is very much possibly an issue. Can you get some el-cheapo whitebox PC that can run WinXP or something? Most readers have a “home” key which is used to tell the reader when you are sending commands to it rather than just typing stuff. So NVDA is Insert and since JAWS uses that for lots of stuff it might be the “JAWS” key too. Orca has an Orca modifier key. Often these are different between whether you have a Desktop layout or a laptop layout. I’m so happy my laptop has a full Desktop layout : )
Usually you can set some other key as your reader home key though.

You might have accidentally turned on the “start speaking as soon as you start up” on NVDA. This is an option and so far as I know it’s off by default when you install, just make sure nothing’s checked when you do the wizard. Then later you can turn it on using a Desktop shortcut and you can quit from the little window it opens (I run JAWS from USB so I start from the start menu, but you can quit from the little JAWS window).

One sucky thing about VoiceOver: it’s Engrish-only. I was in a Mac shop in Rotterdam and we got it going but there were no languages. According to the seller guy it was like that even if you got a Dutch version of the OS. Bleh.

I didn’t watch this, but someone made a video of using VO: http://www.youtube.com/watch?v=pZuCx-Gry6k
is it useful? The comments are making me laugh.

So, my question: are screen readers really so hard to use and/or test, or am I missing something?

They’re not hard for basic test, but I would get used to one before testing anything. Just wander around and then later start visiting websites you visit and do what you normally do on them.
For JAWS I just made a cheat sheet of the stuff I wanted/needed to do, and you can use the mouse and click on stuff to start out if you want. That’s not cheating. Slow the voice speed down (ins + pagedown I think, do this while it’s speaking) and stop SayAll (ins+down arrow in both JAWS and NVDA) and go from there on your own time.

In your free time, listen to MC Hawking: http://www.youtube.com/watch?v=89jt7zJzkNQ
although that was not done in JAWS but some speech synth software that’s no longer made, but… close enough.

3

Thanks for your long reply! Very interesting. I guess I’ll have to stick with VoiceOver for now, and maybe rustle up an old PC at some point later.

I did watch it, and it shows a lot of things that can be done, but gives no indication of how you access those features. :confused: Only at the end does it give a handy tip: Press Control + Option + F7 to get a menu. Only problem is, nothing happens when you press that key combination. :headbang: I’m starting to wonder if the instructions online are for older versions, as most of the key commands don’t work. Seems silly to change them, though. I can tell that video is of an older version, as the voice is much more robotic that the smooth, mellifluous default voice they now have.

Guess I’ll just have to persevere and stop whining. It would be nice not to have to get another degree just to test out a bit of screen reading, though.

4

Maybe there’s a gremlin in your keyboard. Usually major key combos don’t change from version to version… this is why usually if someone starts with JAWS, they don’t switch to Window-Eyes etc. I suspect this is why NVDA is very similar to JAWS, so JAWS users could switch over with less re-learning.

5

Yep, good suggestion, but using another keyboard didn’t help. Had more ‘fun’ with it today. Did get a bit further with browsing web pages, but still confuddled. Perhaps some of the key strokes that don’t work are only browsing applications other than Safari—ˆ’m not sure yet, but that’s the only explanation I can think of. I’ve come across 6 or 7 online tutorials that all recommend key strokes that don’t work, though. curiouser and curiouser.

I’ve been experimenting with accessible forms. I’ve not tended to use fieldsets and legends in the past ( :eek: ) but am doing so now. I read that if you use a legend (even if it’s offscreen) the screen reader will read it out before each form field. E.g. Contact Us, Name… Contact Us, Email… (Is that still true of any screen reader?) VoiceOver doesn’t do this. It just reads the legend once. So it made me wonder what the value is of testing a site in a screen reader anyway. If each one is different, isn’t it best just to make sure that basic accessibility guidelines are followed (like maybe having a fieldset and legend and labels linked to form fields), and then not worry about how the various screen readers handle these? Or is there some other reason to care how screen readers behave?

6

I read that if you use a legend (even if it’s offscreen) the screen reader will read it out before each form field. E.g. Contact Us, Name… Contact Us, Email… (Is that still true of any screen reader?)

JAWS did it, but not with the main legend. It does it with sub-legends, and stops when you go past that sub-fieldset. And, I forget now what I did, but I could turn that off. This is of course why long legends are evil (that and FF doesn’t wrap them usually so they might go off-screen… have to block them for that):
http://www.rnib.org.uk/professionals/webaccessibility/wacblog/Lists/Posts/Post.aspx?List=be9c76d3-7ad0-4e03-a1a0-e6f6953b8178&ID=40

Old but still holds true. So, test a form with a sub-fieldset (like you would have if you had a group of radios inside a form with other questions outside that subfieldset).

I’ll have to see what NVDA does.

So it made me wonder what the value is of testing a site in a screen reader anyway.

It’s the same with browsers. Testing in one browser does not show you all the quirks on your page the users of other browsers may come across. Thus, testing in all the major screen readers would be of most benefit.

Since the things are expensive and take time to learn how to use and are OS-specific, this isn’t what most developers do. Instead, they usually rely on other developers who DO test certain code setups in major readers. Like I’ve been checking this guy out (I guess twitter is useful for something as that’s how I found him): http://www.accessibleculture.org/research/
There are other sites with results of tests, like juicystudio.com but a lot of them I find are old. Brothercake did a bunch of testing at some point, and already his results are no longer valid for newer readers (again, we have no way of knowing how many people are still using older readers!).

If each one is different, isn’t it best just to make sure that basic accessibility guidelines are followed (like maybe having a fieldset and legend and labels linked to form fields), and then not worry about how the various screen readers handle these? Or is there some other reason to care how screen readers behave?

I’d say in general, yes, just follow WCAG, but then add’lly be aware of any particular bugs that are nasty. If you are aware of the bug then you as developer can decide whether you are going to code around it or not. As with anything else. On top of that, besides using your site in a (free) text browser such as Lynx or Elinks (just to get a better feel of the logical flow of your code and content for those browsing linearly), just getting around in one screen reader I think just gives you experience from some user’s point of view. I still consider myself an example of a “novice” user, except I do use the quick keys and don’t just tab through anything. Novice users may make use of skip links (intermediate and above users don’t need them), and possibly bringing special information to their attention (like google.com does… first thing you hear is “Screen reader users: here’s how to turn off Google Instant” which the pro’s may have already figured out (yeah it caused problems in a few readers including Orca).

I also kinda don’t go past JAWS, Window-Eyes, NVDA, Orca and VoiceOver since I’m not sure if you get a userbase large enough to bother worrying about (like we don’t do anything special for browsers like Epiphany or even necessarily Konqueror) for the other readers… but because they are expensive, unlike browsers there might still be a lot of user with stuff like HAL, home page reader and whatever else was out there.

I’d say screen magnifiers (at least one) are also good for testing in. Users may or may not use a screen reader with them (I get lost, I need the reader to use the mag), but this has design implications especially with apps. JAWS comes with MAGic, you should try it out!

Braille… I don’t think there’s anything we can really do about that. It takes years to learn Braille, it costs an arm, leg, first born and a pot of gold for a refreshable braille machine, and by then we’re not doing web design anymore.
So input from others is best, or watching videos.
http://accessites.org/site/2009/06/refreshable-braille/ <–pretty cool

7

Nice reply, poes (and nice to see my fav cat avatar back :smiley: ). That fieldset article was a good read. Thanks for that. I still haven’t figured out when it’s “ok” and when not to omit the legend (when using fieldset), as sometimes a form seems to validate without it but other times not. (I haven’t worked out a pattern.)

By sub legends, do you mean that there is a main fieldset + legend for the whole form, and then within that sub fieldsets each with its own legend?

Good point about screen reader testing being like browser testing. Not that I really wanted to hear that, of course!

using your site in a (free) text browser such as Lynx or Elinks (just to get a better feel of the logical flow of your code and content for those browsing linearly)…

I always turn off CSS to see how the page flows. Is this the equivalent, or is there some special advantage of trying Lynx etc?

Novice users may make use of skip links

This almost seems to suggest you think this is a waste of time? I presume seasoned users have quicker ways to jump to content? Perhaps by jumping from header to header?

I’d say screen magnifiers (at least one) are also good for testing in.

Cripes, I’ve never even heard of them! How is that different from page zoom? I think there are some pretty powerful page zoom facilities on the Mac.

An yeah, braille… I don’t think I even want to go there. :frowning:

8

as sometimes a form seems to validate without it but other times not. (I haven’t worked out a pattern.)

Here’s the pattern (haha):

In HTML4, a legend MUST accompany a fieldset. In XHTML, this requirement has been (strangley) dropped.

BUT
if you are using blocks (divs, p’s) to wrap label-input pairs with an HTML4 doctype, the validator misses it when you leave out legend. If you remove the divs and still have no legend and re-validate, you’ll get the error message you’re expecting (fieldset not followed by a legend). I just assume I should always have a legend with my fieldset, BUT there are times where I can’t think of non-redundant text. In these times sometimes I consider leaving the thing blank. I haven’t decided even today what is best, and some of my forms start with “fill in” (where later fieldsets have useful legends because then grouping-by-type starts).

By sub legends, do you mean that there is a main fieldset + legend for the whole form, and then within that sub fieldsets each with its own legend?

Ja:


<form...>
<fieldset>
<legend>Rate your Coffee Addiction</legend>
 some random questions who have nothing to really group them, but have to do with coffee addiction
  <fieldset>
    <legend>How often do you consume coffee?</legend>
      <input type="radio" name="rate" id="never" value="never"> <label for="never">Never</label>
      <input type="radio" name="rate" id="daily" value="daily"> <label for="daily">Daily</label>
      <input type="radio" name="rate" id="hourly" value="hourly"> <label for="hourly">Hourly</label>
      <input type="radio" name="rate" id="iv" value="constant"> <label for="iv">Constantly via IV drip</label>
    </fieldset>
 rest of form...
  </fieldset>
</form>

“How often do you consume coffee?” may be read out before each question. Depends on the reader and again I thought you could also turn it off.

I always turn off CSS to see how the page flows. Is this the equivalent, or is there some special advantage of trying Lynx etc?

Hm, Lynx has its own ways of showing me where I am, what’s clickable, how tables and forms are set up… whereas turning CSS off (if you do it with the web dev toolbar) you may still have that default browser-specific stylesheet. But, not sure if it matters, they are often all similar to each other. When I’m using Lynx, I’m in the terminal, and I kinda just get into a text-terminal mood : )

This almost seems to suggest you think this is a waste of time? I presume seasoned users have quicker ways to jump to content? Perhaps by jumping from header to header?

Once you are familiar with both a page and your reader, you will use all sorts of ways to navigate. Jumping by header is very nice (assuming the page is well-built and has headers), but navigating through a site… you may want to get to the main menu on each page until you find something you’re looking for.
You can use ARIA attributes (set role of “navigation” to site navigation, “main” to main content, “banner” to a block of info usually containing logo/site name and utility menu and tagline or whatever, “search” for the site search area…) as landmarks to jump to things, or you can use the Quick Keys to jump to things:
next (or prev) header
next (or prev) list <– often the menu
next (or prev) non-link text
next (or prev) form <–often a log in form or search
next (or prev) table
and more

more about ARIA: http://www.nomensa.com/blog/2010/screen-readers-and-aria-landmark-roles/

These are usually faster than tabbing around or hoping the author left some skip links for you… in fact I tend to keep skip links around for sighted keyboarders who aren’t using Opera (since i usually pull the things off-screen, Opera does not offer them as a tabbable option) where they do appear onscreen once focused on.
Try a page like Wikipedia. You can get really quick at getting where you want.
I tend to stay away from accesskeys though SitePoint uses them and users have used them (but a site you revisit often like a forum or news site is more likely to have accesskeys actually benefit users… for a one-off site, you run more risk of people not wanting to memorise them and that they possibly interfere with some other command… like 1-6 can quick jump to that header level).

Cripes, I’ve never even heard of them! How is that different from page zoom? I think there are some pretty powerful page zoom facilities on the Mac.

They’re worse.

Imagine the only part of a web page you can see is the size of a credit card.

Now imagine you’ve clicked on a link and you don’t see anything happening.

Hm.

Because AJAX changed something… on the other side of the browser. You missed it.

So it’s like extreme zoom, depending on how much magnification you need. The problem with it is how it limits the amount of page you can see at once without moving around. So it mostly affects things like user notification.
I’m sure there’s a WCAG rule about where user focus and notification shoudl go.

On that note, adding updates to a page with AJAX (no refresh) also is a good idea to put the change (or a notification of the change) under/after where the user was focussed.
2008: http://northtemple.com/2008/10/07/javascript-and-screen-readers
2006, so is not entirely true for newer readers: http://articles.sitepoint.com/article/ajax-screenreaders-work

Again readers without a virtual buffer don’t have to worry about updating that buffer… they’ll just continue reading the actual page (Orca).

9

Great post again! Thanks for all this info. I will chew over it slowly. :slight_smile:

10
Off Topic:

Hmm, I have answered this question recently but it got vaporised <grumble> so I’ll give you a shortened answer, again - where it won’t get deleted.

Obviously XHTML 1.x and HTML 4.01 differ and certain things were addressed. You are correct the LEGEND (inline) ‘Fieldset Caption’ must appear directly with the FIELDSET (block) in HTML. Because it is the strictly associated text value for the “form control group” so it is basically a no brainer. LEGEND must be the first element within the FIELDSET.

Whence in XHTML the FIELDSET element is used to group form fields and only one LEGEND (inline) ‘fieldset label’ element should occur in the content and if present should only be preceded by whitespace.

The FIELDSET may contain either a ‘block’ or ‘inline’ thus in a sense it’s implied since in essence LEGEND is inline but obviously a block element like DIV could also appear before it was essentially flow, i.e. UL > LI

It’s either an oversight or because FIELDSET got redefined so that either block or inline could occur. Obviously you still get a grouping but it is less accessible.

11

The FIELDSET may contain either a ‘block’ or ‘inline’ thus in a sense it’s implied since in essence LEGEND is inline but obviously a block element like DIV could also appear before it was essentially flow, i.e. UL > LI

Even so, you’d still think an error would be flagged if a legend child is not seen inside a fieldset.

It’s either an oversight or because FIELDSET got redefined so that either block or inline could occur.

Or someone @ w3c wanted to remove the “required” legends and have them optional?
http://centricle.com/archive/2005/06/fieldset+legend-xhtml-html

12

The LEGEND is flagged as an error (if present and misplaced) but since it is all pretty much flow content it cannot really do much about it.

Albeit the main problem is they cannot actually detect “other content” prior to the LEGEND, which MUST be whitespace only. Essentially it is probably still implied.

13

I will jump in here, sorry for the delay. I was out of town for a week. People often think of screen readers as these cute little programs that allow people to read the webpage or a word doc. What they tend to fail to recognize is that a screen reader takes over full control of the computer. Think of a GUI to control a GUI, but the control doesn’t have an actual GUI, it is just audio.

When you first use JAWS, you should take note that the num lock key is turned off. The ins associated with the 0 on the number pad is the ins all the key commands use, vs the ins near backspace. The ctrl key is your best friend, it tells the screen reader to shut up.

What version of OSX are you using? the older versions are pretty crappy

Screen readers have an extremely steep learning curve, so you cannot just pick it up and go. you can figure out that the arrow keys in conjunction with ins allow you to read words, characters, sentences, paragraphs. So if you are using one for testing you just have to keep trying. If you are learning it to help a family member who is or going blind, I recommend you having them get trained at a place for blind people. In the US they are usually called Lighthouse for the Blind. Screen reader software is pretty good, except if you are dealing with the newest thing, then you are maybe looking for trouble. For screen readers on the Windows platform, they are grabbing controls that are exposed via MSAA. If new stuff that cannot be figured out by MSAA, your screen reader can’t see them. I don’t know how often MSAA gets updated.

Don’t give up, they are not something you can pick up and go to town on.

I try not to suggest the screen reader and screen magnifier combination to new people. It is very taxing of computers, and can cause blue screens. I have never used MAGic, I have experience with ZoomText. However ZT is only a one-time 30 day trial. When using ZT and JAWS with each other, they sometimes compete which software has the priority.

Refreshable Braille displays work in conjunction with the screen reader, or at least the one I had access to. It showed whatever the screen reader spoke with some more info (ie h1 [heading text]). You don’t need to test for Braille, if the screen reader reads it, the RBD displays it. If the screen reader wasn’t launched, the RBD didn’t do anything, just kept saying I am here, ready and waiting (in Braille, not literally).

14

Thanks rguy84.

The latest.

Screen readers have an extremely steep learning curve, so you cannot just pick it up and go.

Yep, o well. I have been persevering with VoiceOver a bit. Still reckon it should be easier to do the basics, but I’ve managed to test a few things at least. Was able to test a nav list with a dropdown section—and compare the effect of display:none with pos:abs on the sub menu, which was interesting. Also have been able to test various form layouts.

The basics of any program should be simple, though. If I open Safari with VO on, it’s not too hard to get it to read out “HTML element”… but then it gets stuck there, and there’s no obvious way to get it to read out the web page, which is silly. It’s only by opening up a list of header elements and choosing one of them that it engages with the page. Then it could do one of several things, like read rapid-fire through the whole page, or settle on one element… seems a bit random. Just not well thought out, IMHO.

15

Here’s a question: I was testing a web form with error messages displayed inline (that is, just above the form field).

I first added the error message as a span within the <label>. That worked fine, except that testing it with VoiceOver, the error message gets read twice (as the label on its own and then as the message when you tab to the input area).

<label for="comm">
Comments<br>
<span class="error">This field is required</span>
</label>

Then I tried the error message as a <p> below the <label>, and it seemed to work better, as least with VoiceOver (the error is only read once, after the label, and it is easy to click back to it if the error is forgotten).

<label for="comm">Comments</label>
<p class="error">This field is required</p>

I’ve heard there can be problems with <p>s and other elements within a form—some screen readers ignoring them or something. Any thought on these two setups? As I say, the <p> option worked much better in VoiceOver, and seems more user friendly to me.

16

JAWS ignores non-form-control text, when you’re in Forms Mode, but you can exit Forms Mode to get the other text read out to you. NVDA will switch out of Forms Mode to read out non-form text. Window-Eyes at least used to be like JAWS but not sure about now.

One thing my current copy of JAWS does that isn’t right is, with checkboxes and radio buttons where I have labels with the for attribute, I get the label read out to me three times. This has been going on for a while now and pissing me off… nobody else seems to have this.

I’m actually planning on making a form for testing, somewhat like Jason Kiss’: http://www.accessibleculture.org/research/title-attributes-as-form-control-labels/
and seeing what my readers do.

17

Hrmmm, but how do you know you need to exit form mode? That’s a bummer, really.

The form on Kiss’ site is interesting, a Mike Cherim job. Quite interesting to explorate.

18

[QUOTE=ralph.m;4734037]Hrmmm, but how do you know you need to exit form mode? That’s a bummer, really.

The form on Kiss’ site is interesting, a Mike Cherim job. Quite interesting to explorate.

EDIT: I’ve started to wonder about displaying errors for non-sighted users. If the page reloads and there are errors, what’s the best way to alert someone of this? If the page repeats all the head section, logo and stuff, the user might have to dig a fair way into the page to discover the Error! message somewhere down the page. It’s making me thin that the error page should just start with the title “Error!” as an H1 so that they have a fighting chance. This doesn’t even happen on the Kiss site, though.

19

What I do for form errors:

The title is read on page load (because after submit, a new page is sent to the user), so the title changes to “Error: your form was not submitted”

The skip link to content changes text to say “go direct to the error list” (I’m not sure if that’s a good idea to have that take the place of the normal “skip to content” link).

The h1 changes to something similar to the page title.
Under the h1 is an error list, which are hyperlinks.

Each error listing describes the error “You must be at least 16 years of age” for example.

Clicking on this will take the user to the error on the form. The form has been changed: now there are anchors as destinations with id’s like “Error1”, “Error2” etc (so, this must be generated on the back end). Whether the anchor text is read out or not, it’s the same as above, and either way can take the user directly to the problem question (this is also nice for everyone else too, esp if it’s a long form).

I have in my version an experimental anchor afterwards, called “next error” which can then skip the user to the next incorrect field, or if there is no next incorrect field, the submit button. Since this isn’t typical in forms it breaks some conventions, so I’m not sure if it’s worth it or just added confusion. We ended up not implementing that mostly because the back-ender thought the code would get too complicated on his end.

http://stommepoes.nl/Autoverzekeren/autoberekenfout.html - hover near the top left of the page to see the skip link.

Most importantly is the new text at the bottom: give people an out if they just can’t figure things out. The promise of talking to a human can convince someone who’s having trouble to still do business with you instead of giving up. You can’t ever build for everyone.

I could get to each error in JAWS back when I tested, but I don’t seem to have my English testing page anymore. I’d have to rebuild that to retest (since listening to Dutch pronounced as if it were English is impossible to follow).

(*edit actually I’m busy redoing that form page anyway, where now my regular form has the error-links built-in for my colleague but commented out… and this new page is using ARIA attributes, so at least modern readers are getting more chance of reading error text. I can make an Engrish test page and test things out (to see how the ARIA-attributes are working) and I can post this here when I’m done so others can test in their readers).

Right now it’s something like


	<a id="Error3" class="warning" href="#void"><strong>You have not filled in the brand:</strong></a>
	<label aria-describedby="Error3" for="Brand">Brand:</label>
	  <input type="text" id="Brand" name="Brand" maxlength="15" value="">

or


	<a id="Error1" class="warning" href="#void"><strong>You must be at least 16 years of age:</strong></a>
        <label aria-describedby="Error1">Birth date: </label>
        <label class="ac" for="BirthdateDay">Day: </label>
          <select name="BirthdateDay" id="BirthdateDay">
            <option value="1">1</option>
            <option value="2">2</option>
            <option value="3">3</option>
            ...etc...
            <option value="31">31</option>
          </select>

There is a problem sometimes with multiple labels, but this is the best I’ve gotten without wrapping a fieldset around them, which I’d rather not do because
a: it’s a single question artificially spit into three, and the spirit of fieldset is to group several questions
b: Mozilla makes things a pain to style.

20

Nice reply, Stomme poes. Wow, listening to your page in VoiceOver was worth the price of admission! Dutch in a US accent—hilarious. Hmm, selecting those error links with VO didn’t jump to the form fields, though. :confused: What a pity these readers behave so differently. Still, I like the idea of a list of errors that are also links to the field areas. Do let us know when you have that English version ready. :slight_smile: