South By Southwest (SXSW), March 9-18 2007, Austin, Texas

This is the transcript of the power-session Accessified! Practical accessibility fixes any web developer can use, presented by Ian Lloyd and Patrick H. Lauke at SXSW2007, Austin, Texas, 11 March 2007.

See the related slides (PowerPoint / 6.5MB) and separate screencasts on YouTube.

The audio recording is available from the SXSW podcasts and archive.org

Accessified! Practical accessibility fixes any web developer can use

Ian Lloyd: Good afternoon. I have to say it's good to actually see some people here, because it's kind of ironic with the ... all the accessibility panels being in this room, and it's arguably one of the most inaccessible rooms here. I mean, did you come up by the lift? Crazy.

So you all got here. Fantastic.

We're going to fly through quite a lot here, so we'll just keep it as brief as possible in the introductions. I'm Ian. I have a site called Accessify.com, and this is Patrick, who can be found at splintered.co.uk. Patrick works for Salford University in Manchester. We're going to be using his site in some of the ... his university site in some of the examples today.

We're both members of the Web Standards Project Accessibility Task Force, otherwise known as the WASP ATF.

First, a little bit about ...

Audience member: Can you be louder?

Ian Lloyd: Yeah, I'll just go right next to the microphone.

First, a little bit about what we're not covering today. We're not going to be going through the fine details of WCAG 1.0 or 2.0. You won't hear any reference to any checkpoints or priority or anything like that.

We're not going to be covering any expensive tools that you have to pay lots of money for. And we're not going to go into anything too advanced or experimental.

So what we are covering is ... we're going to demonstrate a few tools that you can use for free to help you on your way. We're going to look at some evaluation tools that you can use in your browser to just see how accessible your pages are. And we're going to be doing this mostly using prerecorded screencasts, and given the somewhat flaky wi-fi here, I have to say, with hindsight, that is a good thing.

So, I'm going to kickstart the first part, where we're going to look at a few tools on Accessify.com. I'm going to just show you the table builder, a form builder, and List-O-Matic, just to give you a feel for some of the tools that are on there that you can use.

So, kicking off with the table builder. If you guys go to Accessify.com/tools-and-wizards — and that's with hyphens, in case it wasn't clear — and it's the first link on the page. So, you click on the link and we can get started with building our table.

There's a bit of preamble there, you need to know, obviously, how many columns you've got, how many rows you've got, what the table headings are going to be. And one thing I will mention, it's only going to create fairly simple tables, there's no rowspans or colspans or anything like that involved here.

So, just sort of setting out the scene here, and ... OK. The first stage, what you want to do? Is it a simple table or a complex table? If you're not entirely sure what the difference is, there's an explanation there that you can follow — it's really a case of using the scope attribute in the table headers, or are you going to use the slightly more complicated headers and IDs.

For this example, we're just going to go with a simple table. Pick a color scheme, and continue on our way.

OK, so the next stage, you get a ... there's a graphic here just explaining one of the things on here, about where's the position of the last header row. Have you got two header rows, or do you have just got the one? How many columns do you need? We're going to say four.

We could say that the first column contains headers, but in this example we're going to uncheck that option, and keep it as simple as we can for the purposes of the demonstration. Give yourself a few rows to play around with, and last header row is position one.

OK, so now you can start beginning to create your table. You need to put in a title attribute ... sorry, not title attribute, the title here which will create a caption element. And in the next field we have the summary attribute — this will create for you the summary attribute of the table tag.

I'm just going to speed on the movie, just a little here, just to speed up my typing.

So, you can create the table headers like so.

OK, so we're nearly done. The table is nearly built. What it does ... has recognized, though, is that the table header on a couple of them could potentially be abbreviated. So, we're going to just show you how that works. You can just edit those, and insert those changes, and you'll see the result in just a moment.

OK, so there's your table completed, and you can see the summary attribute has been put in automatically for you. The caption element is there. Then we have got the table headers with the titles that we put in earlier, and as you can see the abbreviation attributes for the home and the work contact numbers. So very quickly you create a nice accessible table.

One thing I should mention, though, is the ... first of all, there's a class "first column" that you could style if you wanted the first columns appear differently but not actually be a table header. The other thing is, it automatically generates odd and even classes, so if you want to style alternating rows you can do that. A preferable way probably to do it would be using JavaScript and we can't show that today, but there are various techniques out there that you can use to create a dynamic alternating row colors [editor's note: such as splintered striper]

So the next tool we are going to look at is the form builder. Really, really simple tool. We just go back up to the accessibility tools menu, and it's the second link on the page. And you have got a choice of CSS or table layouts, I think you know which we are going to go for ... no table layouts here. So, OK, really, really simple. What form fields do you want to capture? You just type them in here. And I am just going to speed forward just to save time. So, what do you want, type it in there. Just carriage returns.

What do you want to have as the form legend? And there is an option there to include title attributes. Now what that would generate is a title attribute on the form input that just describes what the form input is and it picks up the values that you put in the first box. It's optional, I probably would leave it out now because the screen reader users are probably able to find this information out anyway, but it's an optional thing.

So you can see that we have created the form there with the label elements correctly linked up to the text ... sorry, linked, to the form inputs, and by default it gives you an input size of 20 — that is just an arbitrary value that was chosen. Again you could edit that if you so desire.

Let's just have a quick look at the form then. It's unstyled, but the basics are all there, and if we click on the text we can see that it has generated the labels correctly and it's putting the focus on the form inputs.

OK, so, that's the second one. No, no, I mean I could have put these things in but I just try to keep it simple. OK and the last one I am going to just demonstrate for you is List-O-Matic, which generates list based navigation because all of the cool kids are doing it.

OK, come on, wake up ... there we go. You have to just step up a couple levels on this. Go back to the Tools and Wizards page and scroll down a little way, where you will find the link to List-O-Matic.

OK so what have we got here? How many links do you want? Do you want title attributes in the links? That, again, is another optional thing ... if you want to put the title attributes in it, it is just so you can expand the text there. Again I'm just going to speed forward a bit here so you just imagine I'm typing really, really fast.

OK, so you can see that it's fairly simple. What's a link text? What's a link title? If you want it to expand upon that a little bit and the destination so ... let that carry on there.

So ... oops ... that wasn't meant to happen.

Right OK.

I've done it again!

[laughs]

I will get that right. Step away from the keyboard. [laughter]

OK so you're present now with the unformatted list it is not completely unformated, because it's inheriting some styles from the page that it's contained on, so the bullet points are missing there ... but that's your basic unstyled list. You can pick a style from the gallery there. We've got horizontal or vertical styles. And how do you want to reference this? You can reference the navigation by ID or class — the default is for ID. I suggest just leaving it like that.

And ... so there is the list. Really, really quick to do and it creates everything for you, nice standards ... web standards compliant HTML. You have the title attribute that we put in, and if we scroll down we can see the CSS.

Now, obviously you can edit that and change that and tweak it as you like. But if you'd really want to change it completely, you can simply step back one, choose a different style, go forward again, and, bingo ... there's a completely different style on the list there.

So just a few tools really, to kind of give you a few sections on the page that give you a head start.

With that I'm going to hand over to Patrick, who is going to tell us about evaluating accessibility with toolbars.

Patrick H. Lauke: Yes, as we've just seen, a few tools that really give you a quick way into ... a shortcut into building certain things in the right way. What about if you're getting a page from somebody, or you're asked to evaluate a page, and you really just want to get a quick feel for "Is this page accessible?" or "Does it feature certain kind of characteristics of an accessible page?" without having to go into the markup and kind of analyze it all, or without picking out really expensive tools that give you reports.

So what I'm going to have a look at is just using the Web Developer Toolbar, and using it just to kind of pick out certain things on pages.

So, headings in a page, headings and accessibility. Headings, as you should know, are important. If you've got a big document with loads of sections, obviously screen reader users can take advantage of the headings, they can get an overview of the document, they can navigate directly to the various documents ... aeh, various sections of the document.

Not just screen reader users ... users that rely on keyboard navigation and using things like Opera, for instance, that's got build in capability to actually jump from one heading to the other. So that just makes it easier for the users to kind of navigate your large documents.

So, how can you use the Web Developer Toolbar to check for the presence of headings without having to rip the page apart? So fairly simple, just any page, outline headings ... and it would just give you an overlay, it would just outline them right there and then in the page, so that give you a really quick way to at least check that the author has actually used headings.

If you want to be a bit more specific about it you, can actually get the whole view document outline, and whatever page you're on, it basically picks out, "I found these particular headings on the page", it gives you a list.

That says, "No heading text" there because It's not actually picking up the ... the text itself was actually the ALT attribute of the image on that previous page.

It gives you the big kind of outline of, "These are the headings I found" and you can kind of flick backwards and forwards then, it opens in a new tab, you flick backwards and forwards between the visual view — the graphical view — and this one, and you can basically check "Are the headings all in the right place, does this look like the correct outline for that particular page."

So ... not just headings, it's obviously we're talking about semantic markup, using the right elements to do the right job, really. Why is that important? Well, some assistive technology doesn't really take advantage of all of the semantic markup, all of the various elements, but it's the right thing to do, you know, explicitly saying what the various pieces of content are, and hopefully at some point the AT will catch up with that.

But again, a quick and easy way to check that the correct elements are in the page, without having to break apart the source code, with the Web Developer Toolbar ... so say we're going to a particular page, in this case one of our press release pages, and we want to check in this case for the presence of, "Has the author used any kind of abbreviation elements?" So we can outline custom elements if the option isn't there yet like it is for headings.

So we can put in up to five elements. Say we want to check for the ABBR element, and it outlines it right there, again, visually in the page, without having to go into the markup and actually rip it apart and kind of do find to look around the page.

JavaScript, JavaScript and accessibility ... we're not going to go into the whole diatribe of "JavaScript is evil ... or not." In certain cases it is quite useful, it can kind of enhance usability, and in certain controlled situations it's quite all right to use JavaScript.

But say you want to check on a page that say is on your widely available, outward facing, kind of internet site, you want to check "Does the site works for users that for whatever reason haven't got JavaScript enabled in their browser, or it's not available to them."

Again, with the Web Developer Toolbar, I've got a page here on the Salford site that does use a little bit of JavaScript and there's a warning there at the beginning as well. All it is, it's a big graphical montage, as you're moving your mouse over the various elements, it brings up a little tooltip-like description of what these various elements are.

Now, that obviously uses JavaScript. What happens without JavaScript? We disable it, we reload the page, and we see that yes, the visual effect that the JavaScript was doing is obviously not happening, but what does happen is: that is an image map, as you click through the various numbered links — and you can also do this with a keyboard — it jumps down to the appropriate part, and there's this long numbered list with all the various bit of texts that before used to appear.

So it does work without JavaScript as well so there's a bit of progressive enhancement going on when the page loads. Just to show that again, re-enable JavaScript, reload the page, and you see that that numbered list isn't there. There is JavaScript happening right at the beginning that hides it and then brings it up when you mouse over the certain elements.

Ian already mentioned labels for forms, why they're important ... obviously, if you're using something like assistive technology, having actual labels inside your markup unequivocally ties the text to your form elements. So, as you're tabbing from one form element to another, the AT can actually pick up that particular text without having to use heuristics and thinking "Right, there's a bit of text before it."

Also, usability wise it's good for ... not just for users with screen readers, it can be useful for all users, if you imagine things like small checkboxes, if you actually got a label element that is associated with a checkbox, it makes it a lot easier for users to click on that, because when they click on the label text itself, it checks that checkbox. So it's a lot easier even in situations where the checkbox itself might be a little bit too fiddly.

So again, what does the Web Developer Toolbar give us in terms of forms? There's a whole kind of little menu. We're going to look at, on the Salford site, this really simple search box at the top. You can get a display form information, that kind of overlays it right there in the graphical page.

It might be a bit difficult to tell what's going on there, because the actual page styles are affecting that display, so you can disable the actual CSS and then do that function, and you get the information of "Are there any hidden fields, are there actual labels, etc."

As before, we can also get a separate report in a separate tab that gives us a breakdown of whatever page you were on, how many form limits it found inside actual form itself, what are the various elements, the text inputs, etc. It gives you a breakdown and you can check, there is a column there in the breakdown for label, so that's another way to quickly go through your forms and make sure the ones that need a label actually have a label.

ALT text, that was mentioned in the session this morning. It's ... perhaps the easiest one, but perhaps the most difficult one to actually say authoritatively, "Yes, that's good ALT text or bad ALT text." We're not going to go into any of that debate. We're just going to look at how to use the Webdev Toolbar to check for the presence of ALT text, without actually giving a qualitative "yes that's good" or "yes, that's bad."

So, picking up again the Salford website, the home page is quite heavy on graphics, and it's actually using IMG elements in that page. You want to quickly check "Are there actually.alt attributes there" so we display the ALT attributes, and we can see again, as before, it overlays it onto the actual styled page. This can cause a bit of a problem because, again, you're picking up half the styles of the webdev toolbar and half of the page styles. Again, if you disable the styles for the actual page while you're doing it, it gives you a nicer view, obviously provided that you've used a CSS layout, it kind of linerizes it and breaks it down a lot easier.

You could go through this and check every time you find an image that the ALT is appropriate. You could, once again, also get a separate report which is in a different tab. That pretty much goes through your page, picks up any images it found, and shows various attributes linked with those particular images, and one of those is the actual ALT. So you could print this out if you wanted to, if you have loads and loads of images, you can do it offline. But that's a quick and easy way to go through your page and make sure that ALTs are present.

There are other options in that images dropdown menu. You could also outline images that are missing an ALT, or images that have been assigned an empty ALT, etc. So there are quite a few ways of dealing with images with the Webdev Toolbar.

Ian Lloyd: Now we did actually have a larger section for the other tools, but simply because of time, we've had to cut this down. But I wanted to demonstrate a service called GrayBit.com. This is one of my personal sites and I'm just going to quickly run through it. So you put your URL in the box there. Hit the button that says, "Make it Gray" ... kind of gives away what it's going to do here.

So, we'll see what the effect is. It takes a little while to render it because it's obviously got to change all the images and convert them to grayscale, but you can get a good idea of the color contrast using this tool. We'll just do a quick comparison there between the original and the black-and-white version there, and check the menus. Yeah, everything seems to be OK.

It's a nice quick service that you can run your site through. Another good feature of it is that once you're actually in there, you can carry on following the links in your site and it carries on through. You don't have to keep going back and putting the URL in and going forward each time. It's quite a handy little tool to use. So we'll get to that.

Patrick H. Lauke: Yeah. Online tools, you obviously all know, I would hope, the Markup Validator. Again, I thought I'd just put a slide up there, but again, I won't go into the whole philosophical "Only sites that validate are accessible and vice versa" ... we're not going to touch on that. Obviously, there are situations where a site that might not validate is still accessible, and a site that validates might be completely inaccessible, this just means that you're following the grammar. So it's always a good way ... a good basis to start with, is checking that you're doing the right grammar, whether you then break certain things knowingly because of certain situations that's then up to you to test.

Ian mentioned Graybit for color contrast. Obviously, that's a very subjective way of testing for color contrast, because you're still ... you as the tester, or you as the developer, you go through and eyeball it and say, "Yeah, it's all right. I can tell the difference." If you want something a little bit more authoritative in terms of ... it looks at numbers and stuff, Gez Lemon, a good friend of ours, he's created a little extension for Firefox. Again, you install it, any page you're on, you get it from the context menu, color contrast analyzer, and you can run two separate tests or do a combined test. And what it does is it basically scours your CSS, it goes through and tries to understand any color combinations that might happen on that page, and it looks for the foreground and background color. If the contrast ratio falls below a certain number then it flags up as a failure, and that will be then something you might want to address.

Online checkers. Probably all of us have heard of the infamous Bobby, and there are various other similar tools like, Cynthia Says etc. They all pretty much go through the page, your markup, and test it against WCAG. We said we were not going to mention it, but there we go. So it tests your page against the various checkpoints, which is fine. One tool that I've recently come across, which takes a slightly different approach, is the Functional Accessibility Evaluator (FAE). Again, it's an online tool, similar to all those other tools. You put your URL in and it gives you a report, but this report doesn't actually go through the various WCAG checkpoints. It goes through its own internal set of what they call 'best practices', which are a bit dubious. If you don't quite agree with them, that's fine. But it just gives you a different view. For instance here, I ran the Salford site, through the validator, it warns me that there is a failure there in my navigation and orientation. And as I'm digging further into it, you can go into further levels; it tells you what was actually wrong. It's basically warning me that, because I'm using a lot of order lists and unordered lists, if it's a navigation there should really be a header in front of that, presumably that says "Navigation". Now again, I would completely disagree with that one, but these are the kinds of tests that it does. So there are tools out there that don't just check against WCAG. This gives you a slightly different view ... so make of the results what you will.

And a really quick mention of ... we've almost touched upon that previously, something that a friend of mine, Bruce Lawson, and I dubbed unobtrusive accessibility, just to jump on all the bandwagon of hijax and progressive enhancement and everything else. Unobtrusive accessibility, which really is ... a lot of us developers — I mean I see it in my day-to-day job — we want to do the right thing, we want to do accessibility and make sure that our pages work. But sometimes or quite often, that clashes with the idea that the marketing department has, the idea that the site designer has, you know they're very precious about "I like my site a certain way, you're not going to put this feature in there." So basically, just a little of what to do in those kinds of situations. So, doing the right thing without your boss noticing.

Really simple, it's only three cases and they all pretty much boil down to the same thing. We've already seen the search box on the Salford website, top-right. It is looking at it from purely the graphical point of view at the top there. It is reasonably obvious to somebody whose used a few a websites that the first one, you type in your search term and then you've got your search button. But what if you said, "I really want to put a label in there that kind of makes it really explicit, so that somebody with a screen reader comes along, gets focus on that, they actually know what to do."

If you actually take the styling off that page, you'll see that there is actually a label there, and all of the trickery is that you just use a bit of CSS to hide it from normal view. Now there is obviously the whole discussion of "Don't use 'display none' because some assistive technology then doesn't actually see that at all etc.", but we're not going to go into that. But just hiding form labels ... they're still there in the markup, you're doing the right thing, but then you're taking it away from the default view, so nobody will complain, "Why are you putting that there? It doesn't look nice."

Similar approach, skip links ... again, whether you agree with the idea or not, we're not going to go into that debate. But say you've got a lot of navigation coming before your content and you think, "OK, I might put a skip-link there, so a keyboard user might take advantage of that and jump straight to the content." However, say the designer says, "I really don't want you to have the skip-link there." Yes, arguably, people will say, "Yes,skip-links to be useful,t hey need to be there, they need to be visible and you want to make sure that those people that need them can actually see them."

But, again, it's in contrast with the designer. So what to do? Here we got an example, on the Web Standards Project website. It's using a technique that I first implemented on ... I did a redesign for Molly Holzschlag, I did her design, and Andy Clarke, quite blatantly, nicked my technique. So you've got the page here, that's the graphical view. But on your first tab — assuming that it will be keyboard users that get the most use out of this — on the first tab when you get to the page you actually get a skip link and it appears. So basically, it only appears when you tab to it. Now this is actually an early version of my technique, which also works with a mouse, if you're ... moving the mouse towards the top of the screen, that still appears. I've refined it since then, that it only appears when you're using a keyboard.

Again, your boss or your designer might actually not even know that that's there, but users that might need it or might take advantage of it, would more than likely find it. And because it's in a logical place as well, right at the top, that is pretty much the expected place where they would find it.

Again, another hidden technique I'm using ... this is my personal site, I'm using three tables to show news, projects and experiments.

This is obviously a table, but if you look at it, visually it becomes pretty clear, on the news one, the first column is the news title, and the second column is the actual date when that news item was posted. You might say "OK, I want to make that relationship explicit. I need to put something in the markup there." And if you take the styling off the site, you see that there is a table head there, so columns actually have column headers — properly marked up, it's all there in the markup and once again, using CSS to hide it.

So it basically boils down to: you're doing the right thing, you're putting the stuff in there, and then you hiding it out of the default view.

Ian Lloyd: And we're done. Thanks everyone for coming along. I'm sorry we couldn't ... we had lots more to do here, but time is not on our side. If you want to learn a bit more about accessibility, a couple of good resources you could try is the AccessifyForum.com or join the mailing list at WebAIM.org.

If anyone wants to come and ask us any questions after the session, just feel free. And if anyone needs their little flyer stamped for the competition of the book, just come up and see me. Thank you.

Initial transcript provided by CastingWords, with subsequent editing by Patrick H. Lauke. Released under Creative Commons Attribution-NonCommercial-ShareAlike 2.0.