Boagworld podcast, Season 2 Episode 6: Web accessibility in the real world

My June 2011 conversation with Paul Boag for the Boagworld podcast — audio transcription, HTML5 accessibility support, JavaScript and screen readers, and keyboard access. Originally published as a Simply Accessible transcript, now re-homed here.

This is the transcript of an interview recorded over Skype on June 22, 2011 between Paul Boag, one of the hosts of the Boagworld podcast, and me — posted as Season 2, Episode 6, "Web accessibility in the real world." The audio is still published on the Boagworld site. I originally published this transcript at Simply Accessible, which is no longer online, so I've brought it home here — lightly cleaned for readability from the 2011 original. It pairs with my article Aim for the stars: pragmatism and transcripts.

Interview summary

• Audio transcription: If you're producing audio content, you need to get it transcribed, and should release the transcript and content together.
• HTML5 accessibility: If you're using HTML5, be aware that not all screen reader / browser / operating system combinations fully support it yet.
• JavaScript accessibility: JavaScript on/off is an interoperability issue; most screen readers work reasonably well with JavaScript techniques.
• Providing keyboard access: Keyboard testing is critical, and is very easily testable by developers.

Listen

The audio is hosted on the Boagworld site: Boagworld Podcast, Season 2 Episode 6.

Full transcript

Derek Featherstone: Hello there.

Paul Boag: Hello Derek, how are you?

Derek Featherstone: Fantastic, how about you?

Paul Boag: Yeah, pretty good, pretty good. So I'm checking in, sir, cause apparently I need to talk to you about accessibility, before I get myself in too much trouble.

Derek Featherstone: Well, it's always good to check on things before you get too far down the process. So that's good.

Paul Boag: Coerced, I think was the word we used in our email exchange?

Derek Featherstone: I think there's a certain value to positive coercion.

Paul Boag: Absolutely, I entirely agree. Yeah, I desperately needed to talk to you about this stuff, so it's good that you approached me and I think we need to get into the heart of it because I do actually have a few questions relating to kinda how Boag works. So yes, let's dive in.

Derek Featherstone: Sounds good.

Audio transcription and the Boagworld podcast

Paul Boag: The big one, the big one, from my point of view, Boagworld — I do a lot of video, I do a lot of audio, and I should, in theory, I'm imagining, get transcriptions of all of that stuff done. I don't know where the line is, to be honest, Derek. Because, let's take the audio, the podcast stuff.

Derek Featherstone: Right.

Paul Boag: I've been very fortunate with the podcast stuff that I've got a great group of people that will transcribe stuff, you know, things like this call that we're doing now.

Derek Featherstone: Right.

Paul Boag: And also I have to write out stuff anyway for the show, which effectively is a blog post that I work through. So I guess my question with that stuff is, is it always the right thing to do a transcription, or is there any argument for doing something as an alternative to getting to the same content. Let me explain what I mean. So when I do the podcast, we do a lot of rambling and there's a lot of going off on tangents and that kind of stuff. Now if you transcribe all of that literally and put it on the website, it's annoying, you know. Because it's got all of our tangents off of it and the rest of the place. So I just thought of taking the route of just putting a blog post up there that's a much more coherent, organized breakdown of whatever subject. But is that enough, do you think? Do you know what I'm getting at?

Derek Featherstone: Yeah, I definitely do, and I would ask a number of questions, I mean. Why is the tangential — why is that annoying in a transcript?

Paul Boag: Perhaps it isn't, but it certainly, as I read back through it, it feels like a lot of waffle. You know, cause reading is a different experience to actually listening to something. To some degree Boagworld is the kind of thing you have on in the background. It makes you feel like you're a part of an office environment almost, you know, with other people bickering and discussing stuff. We get onto completely unrelated subjects sometimes about what the weather's like, or where Marcus is going on holiday. It just feels like in written form that doesn't seem to translate very well. And I wonder whether there's an argument for, this is a different medium, we need to treat it in a different way.

Derek Featherstone: Right, and I can see that there would be, that you would certainly feel that for certain parts. I guess one of the questions I would follow up with is, if that banter, and the back and forth, is part of creating the atmosphere that you're trying to create, is there value in having that atmosphere created for somebody that simply cannot listen to the live show? Is that banter coming through in the written format the only chance that they have really, to understand what your relationship is like with Marcus?

Paul Boag: Yeah.

Derek Featherstone: Is that something that helps contribute to the overall feeling that you're going for, just in a different format? So while I completely understand what you're saying, I think one of the things to consider is that, while you're thinking that the banter and the back and forth and the tangential is really fantastic in the primary format — which might be listening — and maybe doesn't belong in the secondary format, which might be the written form: for a group of people, that written form is their primary format.

Paul Boag: Yeah.

Derek Featherstone: So, it may... you know, I think there's a judgment call here that you need to make. But I would favor, in many ways: here's the transcript. Here's the full transcript, which you're going to have done anyway, but then here's the blog post which you're also doing, which summarizes and doesn't include the tangential, or maybe it calls attention to some of the key components. That way you're providing that extra value to everybody and not just people that can hear.

Paul Boag: I guess that kind of brings us on to the second and related issue to this, which is, to be honest, the practicalities of this kind of stuff. I rely on a group of volunteers to do the transcripts for me, which we do where we feel it's relevant and don't where we don't. But to some degree, I am kind of limited on how much I can ask of them.

Derek Featherstone: Right.

Paul Boag: Now, I could go out and pay for services — there are various services around that enable you to do that. But, to be frank with you, we don't really have a budget set aside for Boagworld, which is probably something we should do. But even in a more general sense, there are other people that just don't have the budget to pay for transcription. And there is also an immediacy issue here as well with some of the videos we produce. You think, do we wait, should we wait before there is a transcription and put it all out together? I'm messing up my questions here, but essentially I think what I'm getting at is sometimes you feel like — a lot of people would feel like — if you have to do a transcription, then it may lead to not using the audio, or not using the video at all. Do you know what I mean? There would be an argument, and I'm playing devil's advocate a little bit here: if I have to cater for this minority audience, then essentially I can't do it at all, and so the majority suffer. Does that make sense?

Derek Featherstone: I know what you're saying. And I guess one of the questions that I would ask — and I'm going to ask you probably as many questions as you ask me — do you, for example, have an editorial calendar when you know that these videos are going to be done? We did the same thing: we did a screencast not too long ago, and the topic was called "Images in context." It was a screencast that showed how we need to consider all text. It's not as simple as it seems, so we need to consider the context of the images and how they're being used, and just kind of walk through some examples. We had it recorded, we were ready to go, we could have published it right away. But we also have a great transcription provider that we work with, and so we waited that extra day and got the transcribed content, built it in, and launched it all at once. And I think if you are constantly feeling like you're behind, then you're going to feel, "Well, I've got to get this out there, I've got to get this out there. And I'm going to put it out without the transcript." I think that the planning side of it has to come into play for everyone. And the transcript kind of overlapping the answers to your questions as well — you had mentioned that you don't really have a budget set aside for Boagworld. I don't know that you need a huge budget for it, but, you know, there's a reality that we all have to face. One of the things that people have said for many years is that if you use web standards, accessibility comes for free — but there are real hard costs to providing accessible content, and one of those is getting your content transcribed. You're doing it right now through volunteers, and that's great, but we use a very cost-effective transcription service and it costs me, I think, about a dollar a minute. It's human transcribed, it's absolutely fantastic. We do it for every virtual seminar that we do, for our Q&A calls, for our screencasts, for absolutely everything. And it's just something that we've built into our plan.

Paul Boag: Who is that that you use, by the way?

Derek Featherstone: We are using a group called — let me just pull up the site here, I just want to make sure I've got the right URL — it's The Small Business Transcriptionist that we use, at thesmallbusinesstranscriptionist.com. We use their team and they're fantastic. They've been really great for us, and they've produced things that look just wonderful. They produce for our virtual seminars, they produce transcripts, and they actually go to the point of formatting them and matching our colors, and they use our template and they do that for us. And they're fantastic, really, really wonderful. So, you know, there is a cost and you need to plan for that. That is part of what doing your very best work is about in this case. And the fact that you're doing anything with it now, and you have volunteers transcribing, tells me that you care about it. But I think what you should consider is looking at how long that will take and what it's worth. I think, to be honest with you, you've got a fairly popular show that a lot of people would look to as an example.

Paul Boag: Yeah.

Derek Featherstone: So there is no way, as an accessibility advocate, that I can put something out there that didn't have a transcript available, and captions on our screencast. I just can't do it.

Paul Boag: Yeah, no, absolutely. I think people probably in your position should look at it in much the same way. It's certainly something that I've taken seriously with the podcast, although, like I said, I'm still somewhat torn as to what the best approach is. It's where I've been slack, and I know I've been slack — it's been over the screencasts I've done where I've given a presentation at some conference and I've got a video at the end of it and I don't tend to get that transcribed, where perhaps I should. It's getting the balance right, isn't it? It's a balance between a kind of moral obligation and the return-on-investment issues here. Getting that balance is difficult. But you are right. Because of the kind of work that we undertake, and the kind of things that we do as Headscape, I think it is a necessity and it is something that I need to readdress. So yeah, I entirely take on board what you're saying.

HTML5 accessibility

Paul Boag: Let's turn to — the other thing I want to talk to you about is HTML5, okay? Because all the cool kids are coding things in HTML5 these days. I'm in quite a spoiled position as I look at my website. I've got less than 2% of people using IE6 or IE7. So it opens up a load of possibilities for me in terms of what I can code in HTML5. Before I jumped in, however — I am not as up on accessibility as I should be at the moment. And it suddenly occurred to me, "Hang on a minute, do all these screen readers support all this cool new semantic stuff that we've got going on, you know, sections and the asides and all the rest of it? Or am I going to create problems for myself going down this HTML5 route?" So I thought I'd ask you: what's the situation with HTML5 at the moment?

Derek Featherstone: It's evolving, right? That's part of the reality of HTML5 right now — we just happen to be in a situation where HTML5, generally speaking, works in browsers and therefore people are going to want to use it. You don't have difficulty, even with those older versions of Internet Explorer; we can still find ways to style them and use them as style hooks and access them with scripting because they're part of the DOM. So we've got that ability in browsers to make something where, really, there's no real visual difference. So there's that expressiveness that comes from these new elements that everybody's been clamoring for. I want to be able to use these semantics to our advantage to be able to do things — say, on a blog post, this is the article and this stuff is in the aside. Right now, though, that type of information, that expressiveness, that semantic, is not understood by assistive technology for the most part. That's not to say that none of it is. My favorite example is the nav element in HTML5, which in theory should allow us at some point in the future to eliminate the need for skip-to-main-content links and those sorts of things that are really solutions we put in place to get around shortcomings in assistive technology and browser technology. In reality, you don't even need a screen reader to benefit from some of these things. It would be wonderful for a sighted keyboard user to be able to have access to these things in all their browsers, so that if I'm using a particular browser and I'm a sighted keyboard user, I should be able to use a specific keystroke to jump directly to the navigational items on a website. So that's the idea behind it. Unfortunately, that just doesn't exist right now. All these new elements aren't really worth anything more to a screen reader, or to other pieces of assistive technology, than a div is. They're basically exposed as divs, or the equivalent of a div.

Paul Boag: Yeah, the question is, am I going to do damage using these? I mean, the one that springs to mind is one of the things all of this new HTML5 stuff raises up, is things like having multiple H1s on a page, and that kind of thing. Which I'm guessing could cause problems to screen readers, could it not?

Derek Featherstone: Yeah. And the way that things work right now with screen readers and browsers is that they generally don't understand the new document outline algorithms that exist with HTML5.

Paul Boag: Right.

Derek Featherstone: That whole suite of sectioning content and — I mean, even as recently, I think I did read the other day that the hgroup element, which was designed basically to allow people to create more complicated heading structures within their page, that's even under review now as to whether or not that will continue. There's definitely issues with the document outlines. They don't really understand at this point the new, more complicated / better document outline algorithms.

Paul Boag: Right.

Derek Featherstone: So that's something where you could in theory have 30 H1s on a page. And with the new document outline algorithm, they're not actually all H1s — they're kind of scoped to fit within a specific content block. But to a screen reader right now, those would all be headings at the top level. The other side to balance with this is that there's still so many pages out there that don't have any headings at all, and I don't know why that is. So, we talk about one of the requirements that we've had in accessibility for some time, which is that we should use a logical heading structure, and it should flow, and we shouldn't jump from an H1 down to an H4 — we should really make sure it goes H1, H2, H3, H4 and that we have that logical path. But from my experience in doing testing with real people with disabilities, there's still people that don't even know they can do heading navigation, first of all. Second, in many cases, while there can be some confusion as to what level of heading means what, there's still just a lot of general happiness when headings are used at all.

Paul Boag: Right.

Derek Featherstone: Because, as I said, there's so much of the web out there that just doesn't have headings in the first place. So that's one example. Another — I just wrote an article about this last week on our accessibility blog, and it's called accessibility in HTML5 block links. One of the concepts in HTML5 that we have is that you can wrap a link around block-level content.

Paul Boag: Yeah.

Derek Featherstone: We just didn't have that before — people used to do it anyway but it wouldn't validate. Now we can validate it. But that actually causes some issues, with content being repeated in some cases, content being skipped in other cases, and it really depends on how the — you know, it's all based on, when you have invalid HTML or XHTML then the browsers all have different mechanisms for recovering from what they see as errors. And because the browsers weren't necessarily written to understand HTML5 syntax and what should happen when you have an anchor around block-level content, their error-recovery mechanisms kind of kick in, and you'll see, if you look at things in the DOM tree of different browsers, that they all recover from things slightly differently. Back in the old days, we used to not require closing paragraph or closing list-item tags, because what ended up happening was, when you had a new list item starting, or a new paragraph starting, there was an implied close of the previous one. So the browsers already have that kind of behavior built into them anyway. But when they close things, the results sometimes are a little bit off. So the idea is that, even though we can use HTML5 block links, we really want people to understand the implications of doing so. The fact is that if you have a heading and then a paragraph, and you wrap that in a block link, in certain scenarios the paragraph just isn't read out by assistive technology. So you want to make sure that the important words — or that there's enough identifying information for people to understand what's on the other side of the link — are maybe just within that heading, and the paragraph is more information, in addition, that helps people understand it a bit more, but it's not critical to knowing "is this the link that I want to follow."

JavaScript and accessibility

Paul Boag: Cool. OK. There's one other area that I'd like to pick your brains over before I let you point me at any other things that you think are relevant. The other area that is always of concern to me is JavaScript, and how it impacts screen readers. I've read a lot of stuff on this but I'm still somewhat confused about what it is screen readers actually allow and what they won't — what they will read back to you and what they won't, if you make a new page update or whatever else. And I've taken a bit of a cop-out scenario on this in some bits and bobs I've worked on in the past, where, because I'm so unsure of what's going to be read and what's not, I've gone for the tactic — and it's probably bad practice, you're going to tell me off for it — of putting a message at the top of the page that isn't visible to anybody but screen reader users, saying essentially "click this link to disable JavaScript," in effect, and remove all the JavaScript from the page, so that then everything is accessible without JavaScript in the way. Because it almost seems to create more problems than it's worth. There seems to be so much confusion about what works and what doesn't, at least from my perspective. So what should I be doing about JavaScript-based stuff — but bearing in mind that what I do is designed to degrade nicely if it's not there?

Derek Featherstone: Right. And I think that's always a great practice, having that progressive enhancement approach where things work both with and without JavaScript. That's fantastic. But the reality is — and I think I've mentioned this to you before — that most people with disabilities that are using a screen reader don't turn off JavaScript. It may be off for them, but even then that's not an issue of disability. It's usually turned off for some other reason, like it might have got filtered out at the firewall level, or something else. It's not usually done specifically because "I'm using a screen reader, I'm going to turn off JavaScript."

Paul Boag: What about having — sorry, I probably didn't explain myself particularly well. In the message I have at the top of the screen I put in a link that says "click on this link and the JavaScript will be removed" from this specific site. In other words, they're triggering an event that removes — the rest of the JavaScript will no longer fire on the page.

Derek Featherstone: Even then, I wouldn't say that they even know what the impact of turning off JavaScript would even be. They probably — to be honest with you, you've seen the video that Google did about asking people what a browser is.

Paul Boag: Yeah, absolutely.

Derek Featherstone: The same thing, right? People don't know what JavaScript is. People that use the web don't know what JavaScript is, for the most part. The only time that they know about it is when they get errors or things like that that say there's some JavaScript on this page that failed. They get that in their face then, but they don't necessarily know what it is. So here's the simple philosophy that we use. If you're using scripting and Ajax, and you're doing it for a reason, because it's going to benefit the user experience for somebody — I firmly believe that we actually should be using scripting and Ajax in ways that enhance the experience even more for people with disabilities. So what I mean by that is — and I talk about this quite often — disability issues are an amplifier for usability issues.

Paul Boag: Mm-hm.

Derek Featherstone: So if you have a disability and you experience a usability issue — it may be something that you or I might have a particular issue with a site, and it might slow us down by, say, 10 seconds. But somebody with a disability, it might slow them down by 3 minutes, because of the small usability issue. And likewise, I think that it also works in the positive: so where we include a feature or something with scripting or with Ajax that makes our job easier by a factor of two, it might, if it's done well, increase the efficiency for somebody that's using a keyboard or that is using a screen reader by a factor of, let's say, 10 — because we've improved the interface by using that scripting such that we make it that much more efficient than having to manage things with a non-scripted, no-JavaScript scenario.

Paul Boag: Yeah.

Derek Featherstone: So I think that's kind of the philosophy that we use. Really knowing what scripting is going to be read — I mean, screen readers right now run on top of browsers that do understand JavaScript and that do a pretty good job of it. There are very few days where we've had to look at something and say, "oh, we're using JavaScript for this but we can't use that JavaScript." Ultimately, one of the biggest problems with scripting is that an update happens in the page, and even if the content is understood by a screen reader — which most times it is — there's things that we don't do that help the user understand what's happened on the screen. So you'll pop up a layer, or a — a layer, I can't believe I just said that. You'll pop up a div or a faux dialogue box, and, for example, we don't move the focus to that dialogue box so that it takes the next logical focus point in the interface. Things like that. I've written a couple of articles recently on the Web Standards Sherpa site about some of these issues, on how to use focus to help an interface become more understandable to somebody that can't see it. So what we need to do, if you're popping up that dialogue box — and a lot of the toolkits and libraries are starting to do this stuff for you now — when you pop up that dialogue, we should really place the focus there so that you can interact with that content next.

Paul Boag: Yeah.

Derek Featherstone: There's a lot of issues to keep in mind. For the most part, most screen readers these days are able to keep up with those updates, with very few exceptions.

Paul Boag: Okay. Oh, that's more encouraging than I thought it was going to be. Because sometimes you read these things in various places that make you think, "oh, does that mean I can't use Ajax in this situation?" — but it sounds like a lot of the time it's just down to how that is coded and how that is presented. I've taken longer of your time than I said I would. Is there anything else that I ought to keep an eye on that you think are key issues that I need to be aware of as I go forward?

Derek Featherstone: In terms of what you're looking at for your site, you've hit on the big content-type issues. You're doing a lot of audio and video, so that's really a critical piece for you.

Paul Boag: Yeah.

Derek Featherstone: You know, I think you've hit on all the major things. And I know the JavaScript issue is something that we've talked about before, and I think that is an important piece to understand. The problem with that is, most developers are stuck in this scenario where they just don't know what works and what doesn't work.

Paul Boag: Yeah.

Providing keyboard access

Derek Featherstone: And the only way to really get around that is to do testing. And I think that's probably the most significant part of what people can do when they're building sites and applications: absolutely force yourself to do everything with the keyboard. If you nail keyboard accessibility, you make it that much better for anybody that's using any piece of assistive technology. Because most assistive technology, in some way or another — and that's a very broad statement — most of the assistive technology that you're familiar with is either keyboard-based, or has keyboard emulation and functions like a keyboard from a technical perspective. So if you can deal with providing proper keyboard access — which really means that you're making sure that everything can be done with a keyboard, but also that it can be done efficiently. We've seen interfaces where you can perform a piece of functionality with a keyboard, but it takes you 50 keystrokes to be able to do it.

Paul Boag: Right.

Derek Featherstone: It needs to be not just doable, but it also needs to be efficient. And that's really two of the major keys to this. And I'll send you links to those articles on the Web Standards Sherpa site, that kind of explain it.

Paul Boag: I was just about to ask that. That would be immensely useful. That last piece — as soon as you started talking about testing my immediate reaction is, "oh, but you know, budget and timescales, and this isn't a big project." But that piece of practical advice of just doing everything by keyboard, I can do that. Do you know what I mean? There's nothing to stop me doing that. It's an easy thing to do. And okay, it doesn't replace proper testing, I'm not suggesting it does, but it's a good practical little starting point that I could do right now. And I think just from doing that, I would solve a load of issues. So I like that. That makes a lot of sense to me.

Derek Featherstone: That's the thing. Like you said, it's not — and I wouldn't even say that keyboard testing would be a replacement for proper testing; it should be part of a proper testing, you know. And I think that's a critical piece. There's simple things. Yes, there are more complicated pieces that I would never expect every web developer to do. But I would expect, and really encourage, every web developer to test with a keyboard.

Paul Boag: Yes.

Derek Featherstone: Test everything with a keyboard. Check your heading structure, make sure all your form fields are labeled. Those are all things — everybody asks me this all the time: "what screen reader should I buy for testing?" Don't. You don't need a screen reader to test for things like good structure, keyboard usage, form field labels — you just don't need a screen reader for doing that. And given that screen readers cost, you know, upwards of a thousand dollars, or whatever they cost — not sure what they cost in the U.K. — in reality, I would rather you spend that money hiring a number of people to come in and do testing for you. By that, I mean we'll pay different people in different groups, or we'll get people that are willing to come in and work on things with a screen reader, and we'll test voice-recognition software with people that use it every day. I would much rather spend that fifteen hundred dollars on testing with real people than having my developers test with a screen reader. You get so much more value out of paying real people to do it, and giving them a decent honorarium that shows the value you're going to get out of working with them.

Paul Boag: Brilliant. Thank you very much, Derek, you've given me loads to think about. It is a tricky area. It's easy to let accessibility slip into the background, even when you do care about it, even when it is something that's important to you — other things quickly take over. And I really felt, hey, we need to be talking about accessibility on the show. And you're right. Certainly there's a lot more that I can be doing without necessarily a huge amount of more work, either. It's just thinking about these things more than anything else, isn't it? Very useful.

Derek Featherstone: Absolutely. It all starts with awareness, right?

Paul Boag: Yeah.

Derek Featherstone: So I think that's a big part of this.

Paul Boag: Cool. Well, hopefully once I've got some stuff up and running, I can come back to you and we can have a talk again and you can pick holes in what I've done. How about that?

Derek Featherstone: That sounds fantastic.

Paul Boag: Alright, thanks very much for your time, Derek.

Derek Featherstone: Thank you, Paul.

Paul Boag: Talk to you soon, bye bye.