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 necessary, he told me, are properly associated
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.
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.