Building better forms with Steve Marshall

Paul Boag

Steve Marshall from Yahoo! draws on his many years of experience to share with us best practice in form design.

Paul: Joining me today is Steve Marshall who is here to talk about form design. Hello Steve.

Steve: Hey Paul.

Paul: Good to have you on the show, thanks for agreeing to do this. I think a good place for us to start is a little bit of an introduction about who you are and I guess why form design? Why we’re discussing that with you? So a little bit about those two things would be great.

Steve: OK, so I guess I’ve been working on the web for about ten years or so now, for the last three of them working at Yahoo. And a lot of what I’ve been doing at Yahoo has been on fairly high-profile sites that no-one would really think of, if that makes sense. You know the kind of unsung heroes of the web, that serve hundreds of thousands of page requests a day that no-one really thinks of as interesting websites in our community. Things like Yahoo TV, Yahoo Music, Games, video games – these sorts of things. And I guess really the reason I wanted to talk to you guys about this was it’s kind of a subject that’s very close to my heart because a lot of basic interactions on the web that can be made brilliant for everyone, if only people put a little thought into it – things like: search forms. A classic example for me is on and even on Yahoo Search you have a search box and then you have channels, if you like, for that search so you can say “I would like to search the entire web,” “I would like to search for images,” “I would like to search for video,” these sorts of things. Typically they’re done with links. Now, if a screen reader user, for example, say goes to use that form they can fill out their search keywords, but they will never ever get to those links because in forms mode they don’t get presented with the links in the form. And so you know a little bit of thought about what actually the use case for this form is means you can maybe think about using the right elements for the right purpose.

Photograph of Steve Marshall

Paul: OK, fair enough. That makes a lot of sense. Well, you could come back with the question: “Why does that matter? Why is form design particularly important? Why is it worth us discussing?” How would you respond to that?

Steve: I guess there are a couple of things really. For one it’s essentially using the tools of HTML, CSS, Javascript the way they were intended to be used – using the right pieces of HTML for the correct use. Rather than grouping things in a semantic context, you wouldn’t group list items (<li>) with a paragraph (<p>), you’d group them with an unordered list (<ul>). And it’s just a case of doing the same with forms. Furthermore, though, it allows you to enhance accessibility and enhance usability in general, it means that your forms just work better for all the users of your site, whether they be using full on Javascript-enhanced CSS or if they’re on a really, really old crappy mobile phone that can only just about show HTML forms.

Paul: Yeah. I think as well there’s the aspect to it that forms are a fundamental user interaction on the web.

Steve: Exactly. Particularly given that we’re getting into web applications these days. A really good example of bad use of the web is Google Mail. When they first brought Google Mail out it was all Javascript and all really badly built. And because they did it this way and didn’t want to lose any functionality, they tacked on a basic HTML view. Now if they’d made the page properly and designed it with correct use of forms, correct use of semantics, all this sort of thing, then they could have just progressively enhanced until they got to the point where the main interface is and, for those user agents that couldn’t support all of the funky multi-selection and blah-blah-blah-blah-blah, they could’ve just… they would’ve just not gotten that because they couldn’t support it. And it would mean that they would have one interface to maintain rather than the, and I’m just looking at my Gmail account now, rather than the at least three that they have.

Paul: I mean, the thing is that so often forms are used, you know on an eCommerce site a form is used to make the purchase, you know it’s the call to action. On another site it’s used to signup to a newsletter, it’s kind of really fundamental stuff and don’t often get enough attention really.

Steve: Exactly. There’s a lot of talk about the ‘read-write web’ and the form is the ‘write’ part. The form is essentially the only tool – Flash aside – it’s the only tool that we have in the core HTML, CSS, Javascript bucket that we can use for all users of the web to allow them to contribute back to our sites or allow them to interact with us. So it is very important, but it very often gets really heavily overlooked.

Paul: So let’s talk about some potential ways to make your forms more user-friendly. What kind of advice would you have in regards to that?

Steve: It’s really about going back to basics; stopping for a moment and… you know it’s great to have really flashy ideas for the brilliant, wonderful things you can do with Javascript, but thinking about how your form would be interacted with if you just were using HTML. And a lot of people say “I test my site with just HTML; no CSS and Javascript.” But quite often that goes out the window when they’re talking about forms. A superb example of this is the work that Brad Wright did on Yahoo Answers with their workflow for adding a question to Yahoo Answers. Now there are hundreds of nested categories on Yahoo Answers that you can add your question to and in the Javscript-y workflow, as with quite a lot of sites, you select from the first drop-down and then another drop-down appears with a whole bunch of other categories in it, you know subcategory type things. Now what Brad could’ve done, like most websites, is just present one initial drop-down with all of the initial choices and then another drop-down with every subcategory from every choice, or presented one big drop-down with every subcategory listed with its major category or something like that. And that would’ve worked. It would’ve allowed people to select the right category, but it would’ve meant that you would have to scroll through a couple-hundred different categories to put your question into. What Brad did instead is use nested fieldsets and radio buttons so that you can select your top-level category with one group of radio buttons and then that is essentially the header for a fieldset, if memory serves, and that fieldset then contains the radio buttons for the subcategories of that category.

Paul: Wow.

Steve: It’s not elegant; you do get a really, really big form, but it makes sense and it provides the same level of information and the same flow that you would get with the progressive drop-downs. It’s things like that, just putting that little bit of extra thought in, thinking about how this might work with HTML. To go back to the search example I used earlier I have to – you know full disclosure here, this is something that I did myself about two or three years ago when I first started working for Yahoo and it’s something that various people trumpet as brilliant and I’m very proud of it.

Paul: Very modestly so.

Steve: No, but I feel like it’s an example that gets abused, but it’s a good example. Essentially, everyone as I was saying uses hyperlinks to create the channels for their search. Of course, if you don’t have Javascript, you type your search keywords into the box, you click on the ‘images’ link, for example’s sakes search for images about let’s say ‘Britney Spears,’ and what happens is you get redirected to the Image Search homepage with no keywords. Which will be really frustrating. The way I fixed that, if you will, is – rather than using links, which as I said won’t be presented to screen readers and will lose your keywords, as just two problems with it – I changed them for radio buttons and styled them to make them look like links. It’s a really, really simple change and it just changes the interaction ever so slightly so that people without Javascript, people using alternative browser modes, all these different things, can use that interaction and can benefit from it.

Paul: It’s interesting that you mention that search example. What other kind of accessibility problems are you seeing coming up when people are creating forms?

Steve: I guess most of the problems are around people not thinking about the way that their form would be interacted with in alternative browsers, and the classic example is the screen reader. But things like screen magnification: people may not necessarily group the form fields together or may put the errors away from the form fields to which they’re related and so if you’ve got someone with screen magnification or tunnel vision who doesn’t get quite such a broad view of the page – they only get maybe the couple-hundred pixels that they’ve got magnified – they don’t necessarily have the context of the error message right next to the form and so they don’t get to see that error message and will get frustrated by that.

Paul: To be honest I think that even applies with normal-vision users as well, that if you have an error message at the top of the form and you’ve scrolled down to the bottom, you need to put the error messages where you’re interacting; where the error’s occurring really.

Steve: Yeah exactly. And almost all of this stuff, with a couple of exceptions, it makes life easier for your regular users as well. It just… if it doesn’t improve life for everyone, it improves life generally for a significant enough portion of your user-base that it’s worth paying attention to, I think.

Paul: What about Javascript? You’ve mentioned Javascript a couple of times and although I would entirely agree that you need to use Javascript to progressively enhance a basic HTML version, there are some cool things and some useful things you can do with Javascript when it comes it forms and I was just interested in your opinion about what examples of good Javascript use have you seen with forms?

Steve: The absolute best one, well in fact two, that I’ve seen are on the Yahoo Finance site. One of which is the currency converter. It’s a really simple thing to do a currency converter, or so you would think. But the work that’s been put into the currency converter on Finance is so superb. They do things like: you type into the text box to specify which country or currency you want to convert from and as you type it will intelligently search through lists of countries giving you their currencies if you don’t know the currency for them. Currency codes if you search for currency codes. The full name of the currency and a whole bunch of other stuff. It’s just really smoothly designed. But if you don’t have Javascript, it still gives you a very good base interaction. The other example on Finance is, you have the ability to change the layout of the ‘Top Stories’ page. Changing layouts is something that a lot of people do on a lot of different sites, typically CMS type things. What they’ve done on the Finance site is made this thing work with Javascript, but it’s actually been built so that for screen readers and for various other users it works flawlessly; you don’t necessarily have to be able to see the form to be able to move the items up or down in the list. And quite a lot of people would say: “OK, well you should be able to drag and drop the items.” Well, that’s great, but what about the people who can’t use a mouse, for example… and things like that have been considered.

Paul: Do you think that there is a case where, although something works at a basic level without Javascript enabled, that it’s not always necessary to provide exactly the same functionality?

Steve: Oh, completely. That’s the interesting thing about the likes of the currency converter and the Finance layout changer: it’s the fact that the functionality is not presented identically, but it still gives you the core functionality, particularly with the currency converter – it still gives you the core functionality you want to be able to convert from one currency to another – it’s just that with the Javascript version it gives you much more entry into it, so you can do things like say “I’m going to Guatemala, I don’t know what the currency is, but give me the Guatemalan currency exchange with the Pound.” You don’t have to know that, whereas, with the non-Javascript version if memory serves, you would have to know which currencies you want. It gives you the option to search for them, but to use the interface you would have to know those currency codes. So yeah, using Javascript to provide a different, but enhanced interaction is perfectly fine so long as you can achieve the same results. And that’s the key thing, it’s thinking about what the problem is and what the best way to solve that problem is in the situation you’re in, whether that be plain old HTML or whether that be fully WYSIWYG, Javascript crazy nonsense.

Paul: Heh, “crazy nonsense,” is that a technical term?

Steve: Yes, that’s a very technical term.

Paul: OK, for some of the people out there that maybe are not the Yahoo’s of this world, they’re not the Google’s of this world, that are just basically creating fairly basic sites, what’s the fundamental advice that you would want to give people about form design? What are the things that they should be considering at the most basic level?

Steve: OK, I guess the big thing is, as I’ve said a couple of times, think about what your HTML is doing. By all means think about how you would like it to work with Javascript, but before you start implementing, think about how this should work without Javascript and without CSS. It’s also worth paying attention to accessibility experts in the world because that may impact the way you create copy for your form, for example. One of my absolute favourite pieces of advice is one that Ann McMeekin gave at a talk she did for the Web Standards Group where she told everyone there that apparently screen readers in certain configurations will read out the legend of a fieldset before each and every field, before each and every input within that field. So for example if you have a field whose label is ‘The Web’ and the legend of the fieldset that it’s in is ‘Search’ that’ll be read out as ‘Search The Web’. Try to use these sorts of thing to your advantage, but at the same time at least be aware of them so you’re not flying in the face of your users essentially and making their experience worse. Yeah it is really all about just thinking about what is the lowest barrier to entry, what is the core functionality that you’re working with.

Paul: You mentioned earlier ‘form mode’ for screen reader users. Can you explain that a little bit more? Because I don’t think… I confess I only relatively recently found out about this ‘form mode’ and I don’t think a lot of users realise the consequences of that. Can you explain how that works?

Steve: OK, so – full disclosure, I’m not an accessibility guru, this is all information I’ve picked up from having conversations with our accessibility gurus here. Essentially, screen readers are modal. Because the users of screen readers can’t see the web page, the screen reader presents them with various different interfaces onto the page and you can read through the page as a normal user would in HTML, reading through element by element, paragraph by paragraph. And that’s fine. But when you want to interact, you obviously need different types of controls and so screen readers provide what’s known as ‘forms mode’ and this is a special mode for editing input and working with forms where the screen reader will only present, as I understand it, form fields, labels and titles of fieldsets. So links, paragraphs of text, these sorts of things won’t be presented when you’re in ‘forms mode’.

Paul: That has real serious consequences doesn’t it?

Steve: Exactly, that has massive implications. So quite often people will provide explanatory text after a form field that’s not entirely clear or whose label is not entirely clear, saying ‘You need to fill out this field in this format’. Date fields are a classic example. They will put a paragraph underneath saying ‘Must be in the format ddmmyyyy’ and the screen reader user will never get that because it’s being presented to them in a paragraph (<p>). If the person building that form just took a couple of minutes to rethink the way they were putting the label together and put the label with ‘Date’ and then a <span> around ‘Must be in form whatever’ inside of the label and then styled it however they wanted, the screen reader user would get that and they would get all the advantages of knowing what format it should be in.

Paul: It strikes me it’s all about actually using the form tags that are available to us to the full degree. So many of us don’t use things like groups and legends and all of those kinds of things.

Steve: Yeah precisely. The interesting thing is that these things that aren’t really used are actually really, really beneficial. So for example fieldsets – again, as I understand it, I may be slightly misquoting here – fieldsets allow screen reader users to more easily jump between sections of a form. So if for example you have optional pieces of your form and they’re grouped in a fieldset which says ‘Further Details (optional)’ as the legend of that fieldset and they don’t want to fill out those further details, they can just jump over it to the next fieldset.

Paul: Which, yeah, is amazingly valuable. I mean as soon as you listen to a screen reader and hear how laborious it is, being able to skip over content is really important.

Steve: For those of us who are lucky enough to be fully visually capable and fully able to use motor skills – because of course this, whilst I think about it, this doesn’t just apply to screen reader users, this applies to people who have potentially fine motor skill issues so they have to navigate with a keyboard.

Paul: Which then you get into things like ‘tabindex’ and stuff like that.

Steve: Exactly, exactly. Which you know is a whole other holy war that I dread to get into for fear of upsetting someone. Yeah, these sorts of things again can help with that, and thinking about those sorts of things just makes everyones life easier. Because I mean, for example, I don’t always use the mouse, I will quite often use the keyboard. And I’m perfectly able with my hands and perfectly able to see, but I will quite often ‘tab’ through a form simply because my fingers are already on the keyboard and it saves me moving my fingers a couple of inches… because I’m lazy.

Paul: (CHUCKLES) So you’ve kind of mentioned a couple of people in this that you’ve learned various things from. If people want to learn more about form accessibility and form design and that kind of thing, where would you refer them to? Who do you really respect in this kind of field and you know that they should be following?

Steve: Oh, wow. I guess the people who, in terms of pure accessibility, I would say definitely Mike Davies who goes by Isafarro or Isolani exchangedly, Ben Hawkes-Lewis who I don’t think has a blog, or if he does, doesn’t blog enough. Dirk Ginader who is Those three guys particularly, Ann McMeekin who guys by the name of pixeldiva. All of those guys are absolutely invaluable resources in terms of HTML, CSS, accessibility type stuff. Other than that I have to admit I don’t really know because this stuff is stuff that people don’t talk about enough.

Paul: Yeah, yeah totally.

Steve: So it’s very much a case of scratch what you can find from what’s left on the web, if you like.

Paul: Yeah. OK Steve thank you for that, that was very helpful. It’s good to kind of dig under the surface a bit. So thanks for coming on the show and hopefully we have you on again soon.

Steve: My pleasure. No problem. Yeah, hope so. Thanks a lot Paul.

Paul: Bye bye.

Thanks goes to Simon Hamp for transcribing this interview.