Views From a Screen Reader User
As it concerns using lists and other non-form structural elements to lay out web forms, my feelings have been known. They haven’t changed, but after interviewing an experienced screen reader user about this very subject recently, I do have new insights into it — his perspective anyway. It was a revealing interview. Offering without a doubt relief to some, and probably disappointment to others. Any earned responses will likely determine that.
Tolerance and Survivability
I had once considered writing an article titled “The Blind Aren’t Stupid” to remind readers that just a because a person is blind, it doesn’t mean he or she can’t think on their feet (just like you don’t have to shout when speaking to a foreigner). In other words your content doesn’t have to be written as if it were for a young child and your web site doesn’t have to be mind-numbingly simple or basic to be accessible, usable, and even enjoyable to a screen reader user. In a very real way that premise is supported by what I learned about one screen reader’s tolerance for some of those less-than-best practices I, and others, have warned about.
To put this in terms that apply to web developers, specifically, it means if we do something that isn’t quite right on our sites it doesn’t mean we’ve totally ruined the experience for the blind visitor. A bad web site, like blindness I suppose, is something that needs to be dealt with and overcome, but is survivable. Put another way, most accessible web developers are more concerned about blind users being able to use their web forms, or other elements, than most blind people are, as told by the experienced user I spoke with. Makes sense. It’s to be expected that nobody, sighted or not, will ever understand, appreciate, or even love the finer points of a web site’s design, semantic structure, and inner-workings than a web developer.
Allowance and Acceptance
So what this means, as stated by the user I interviewed, using lists or even tables to layout forms, while certainly not right, won’t necessarily really make the form inaccessible. A tremendous amount, as I learned, depends on the user’s individual settings such as verbosity level, etc. Especially as it pertains to forms in tables. If not in forms mode, and if the right form elements aren’t used, and if the user doesn’t read the table as the author intended (horizontally, row-by-row. probably), then that user may have to rely on the table being constructed with accessibility in mind: i.e, properly done with id and headers attributes being properly used, else, they might be confused by the form and in extreme cases be unable to use it. But in his case, in “form’s mode,” it didn’t make a lot of difference.
I also learned that this user wasn’t bothered by the fieldset elements (even nested). On the other hand, neither did he find them particularly useful either. Again, it didn’t make a difference. I asked about break elements. He had to think, mentioned a slight pause, but he wasn’t entirely sure. And legend elements? They can’t be relied on — he turns them off.
What’s Important
What’s necessary, he told me, are properly associated label and input elements. In my opinion, a list is unnecessary, so is a table, breaks are no big deal (though I like them, they make forms look and stay organized without style sheet support). But being an accessible web developer, I concern myself over these things far more than a user ever will. I seems that as long as I use labels and inputs, it’ll fly for everyone. And required inputs? Since legends can’t be relied on (using them as I do is clever, but only for some users)? He said the star/asterisk in the label immediately before or after the text is best, though he went on to say the word “required” in parenthesis is okay, but longer than it needs to be. Simple.
Proper Direction
Does this means we can start abusing elements or that it no longer matters? Hardly. Being survivable can’t exactly be taken as a free pass to element abuse land. Plus, this is based on an interview with one experienced user so what doesn’t matter to him might matter to someone else. Moreover, future-proofing can only be accomplished by sticking to proper use of markup, in lowercase, with closing elements. Standards-compliance in other words. This is the safe route. Today’s screen readers won’t and can’t announce an important strong or emphatic em tag, and the user cannot set that at this time, but they probably will one day. We have to think ahead.
As developers group together as a single body under the umbrella of web standards, screen reader software writers and others in assistive technology and browser lines are bound to start getting the most out of these elements, more so all the time. So while it’s nice to know that you probably won’t obliterate the accessibility of a web form or other page element by making a simple mistake or not quite using the elements as intended, it might be more critical in the near future.
Gill responds:
Posted: March 25th, 2008 at 12:07 pm →
That’s the crux of the matter. As with all users, disabilities or not, there are different skill levels. Your tester is advanced and understands his reader and its output better than many, so leaving things out based on the preference of one person is dangerous. I prefer to take the approach of design and develop for the lowest common denominator so that they get the experience they need and the advanced can skip bits they don’t want.
Sarah Bourne responds:
Posted: March 25th, 2008 at 1:14 pm →
Although you need to be careful about extrapolating too far from a single case, interviews like this can help you challenge your own (mis)perceptions. I often use my son as a test case for “teens”, but I know him well enough to know that his opinions are his own and may not be shared by any of his peers. But, it’s still valuable if only for showing where some actual observational usability testing would do the most good.
Tommy Olsson responds:
Posted: March 26th, 2008 at 2:35 am →
That was an interesting read. I was a bit surprised that he’s content with an asterisk in the label to denote a require field. I had assumed that an experienced user would have a verbosity setting that doesn’t read out non-alphanumeric characters. But, as Thomas Harris likes to say, to assume is to make an ASS of U and ME both.
Dave Woods responds:
Posted: March 26th, 2008 at 8:39 am →
Very interesting Mike and I completely agree that we should continue to use semantic markup as intended as I suspect that a lot of things like the legend element (which he switches off) is only confusing because it’s not used correctly for the majority of websites.
Browsers have started to catch up in giving us as developers a consistent platform to develop to thanks to web standards and it’s about time the large majority of web developers caught up and started to use markup correct so that we can make screen reader developers jobs easier and ultimately give the end user a much better experience.
Stevie D responds:
Posted: March 26th, 2008 at 9:23 am →
The same is true of any aspect of web design. We’ll spend hours adjusting the colours, shifting things a pixel or two, agonising over how to group elements in a form together, trying out different navigation options, and so on - we want to make the site as good as it can possibly be, in every respect.
The people who visit the site don’t know, and don’t care. If we’d used #82d instead of #82e; if we’d used 2px padding on our list items instead of 3px; if we use a * to denote required form fields or an image of a star with alt=”(required)” … most users wouldn’t notice if they came back the next day and we’d switched all those details round, far less would they think the website was any worse off because of it. Not consciously anyway - subconsciously they might do, but wouldn’t realise it.
Quite. We strive for best practice. “Good enough” isn’t. And just because one screen reader user had a particular set of preferences in no way means that others - who may be less experienced, use different software, or simply have different personal preferences and mental maps - would echo those same responses.
Mike Cherim responds:
Posted: March 26th, 2008 at 1:02 pm →
@Gill: Agreed. And as it concerns forms, that would be to offer at least an associated label for each input (minus submit type).
@Sarah: I’ll say it does! A lot can be learned from simply interviewing an average user. They may have their own thoughts and opinions, but there are always some insights mixed in.
@Tommy: Me too. Very much so.
Amen to that!
@Stevie D: We didn’t discuss that technique, but based on what I did learn I feel pretty comfortable that would be perfectly fine. The only downside I can think of would be them hearing the image announcement, but that shouldn’t be a big deal at all.
naudjf responds:
Posted: March 27th, 2008 at 4:49 am →
Hi Mike,
you say :
But it seems that VoiceOver does (not in the best way but it does…) :