Transcript: Boagworld Podcast Interview with Derek Featherstone

This is the transcript of an interview recorded on June 22nd, 2011 between Paul Boag, one of the hosts of the BoagWorld Podcast and Derek Featherstone, accessibility specialist, author, and speaker. It was recorded over Skype and posted as part of BoagWorld podcast Season 2, episode 6.

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 readers/browsers/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.

Derek Featherstone: Hello there.

Paul Boag: Hello Derek, how are you?

DF: Fantastic, how about you?

PB: 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.

DF: Well, it’s always good to do a, to check on things before you get too far down the process. So that’s good.

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

DF: I think there’s a certain value to positive coercion.

PB: 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.

DF: 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 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.

PB: 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, stuff.

DF: Right.

PB: And also I have to right 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 an alternative to getting to the same content. Let me explain what I mean, right. So when I do the podcast, we do a lot of rambling and there’s a lot of kind 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, you know, breakdown of whatever subject. But is that enough, do you think. Do you know what I’m getting at?

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

PB: Perhaps it isn’t, but it certainly, as I read back through it, it feels like a lot of waffle, and not. 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.

DF: 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 on is, if that banter, and the back and forth, is part of creating the atmosphere thatyou’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.

PB: Yeah.

DF:Is that something that, 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.

PB: Yeah.

DF: So, it may. you know, and I think there’s a judgment call here that, you know, you need to make. But I would favor, I think 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 componentshat way you’re providing that extra value to everybody and not just people that can here.

PB: I guess that kind of brick comes 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 fill is 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.

DF: Right.

PB: 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 have really 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 immediacies issue here as well of some of the, for example, the videos we produce.

You think, do we wait, should wait before there is a transcription and put it all out together or. I’m messing up my questions here but essentially I think what I’m getting at is sometimes you feel like, if you have to do, a lot of people would feel like, if you have to do a transcription, then if may lead to the 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. 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?

DF: 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 calender when you know that these videos are going to be done, so that what you could do and we did the same thing, we did a screen cast not too long ago, and we had the topic it was called “Images in context.” It was a screen cast 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 and 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 can’t, 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 a reality that we all have to face. and one of the things that people have said for many years is that you know if you use web standards, accessibility comes for free, but there are real hard costs to providing accessible content and one of, 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 doesn’t I think it costs me 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 that we do, for our screen casts, for absolutely everything. And it’s just something that we’ve built into our plan.

PB: Who is that that you use, by the way?

DF: We are using a group called, let me just pull up the site here. I believe, I just want to make sure I’ve got the right URL. It’s The Small Business Transcriptionist that we use. And the URL is the smallbusinesstranscriptionist.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 that transcriptionist, even the fact that you’redoing anything with it now and you have volunteers transcribing, tells me that you care about it. But I think what we need to do, or what you should consider, anyway 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.

PB: Yeah.

DF: So, I think, that kind of, and I look at it, there is no way as an accessibility advocate that I can put something out there that didn’t have a transcription, a transcript available and captions on our screencast, I just can’t do it.

PB: Yeah. No, absolutely.

You know, I think people probably in your position, should probably 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 to that is. It’s where I’ve been slack and I know I’ve been slack. It’s been over the screen cast that I’ve done where I’ve given a presentation at some conference and you know the video is, I’ve got a video at the end of it and I don’t tend to get that transcribed where I perhaps I should, is getting the balance right, isn’t it?

If you go cold and callous over this, it’s a balance between a kind of moral obligation and the return on investment issues here. You know, getting that balance is difficult. But you are right. I mean, from because of the kind of work that we undertake, and because of 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 from 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 sides 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 is that 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 that, 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 touse 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, and 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 those solutions that we put in place go 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 key stroke to jump directly to the navigational items on a web site. So, that’s the idea behind it. Unfortunately, that just doesn’t exist right now. There’s no, you know, 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.

PB: 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?

DF: 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.

PB: Right.

DF: 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 to 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 slash better document outline algorithms.

PB: Right.

DF: 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, there’s 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, 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 we 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.

PB: Right.

DF: 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. And one of the concepts in HTML5 that we have is that you can wrap a link around block level content.

PB: Yeah.

DF: We just didn’t have that before and 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 so 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 tree, the dome 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 browser’s all ready 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 block link, in certain scenarios, the paragraph just isn’t read out by assistive technology. So you want to make that the important words or there’s enough identifying information for people to understand what’s on the other side of the link. Maybe just within that heading and the paragraph is more information that is, 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 kind of just, you know, let you kind of point me and any other things that you think are relevant.

But the other area that is always of concern to me is Javascript and how it impacts screen readers and, you know, I’ve read a lot of stuff on this but i’m still some what 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. What’s it going to read and what’s it no. 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, and it’s probably bad practice you’re going to tell me off for it, but I’ve gone for the tactic of putting a message at the top of the page isn’t visible to anybody but screen reader users saying essentially, “click this link to disable JavaScript” in effect and to 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 its 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 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 for, for, because I’m using a screen reader, I’m going to turn off JavaScript.

PB: What about having, you know, 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 not longer fire on the page.

DF: Even then, I would say, 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.

PB: Yeah, absolutely.

DF: The same thing, right? People don’t know what JavaScript 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 using scripting in 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 in 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.

PB: Mm-hm.

DF: 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. Yeah.

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.

PB: Yeah.

DF: 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’s very few days where we’ve had to look at something and say oh we’re using JavaScript for this but we can’t, we can’t use that JavaScript. Ultimately, on of the biggest problems with scripting is that an update happensin 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 lare or a, a lare 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. Thinks like that. And I’ve written a couple of articles recently on the web standard 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 lot of the tool kits and libraries are starting to do this stuff for you now. So when you pop up that dialogue, we should really place the focus there so that you can interact with that content next.

PB: Yeah.

DF: 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.

PB: Okay. Oh, that’s more encouraging than I thought it was going to be then. Because, you know, sometimes, you kind of 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 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 keyissues that I need to be aware of as I go forward.

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

PB: Yeah.

DF: 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.

PB: Yeah.

Providing Keyboard Access

Derek Featherstone: And the only way to really to get around that is to do testing and and I think that’s probably the most significant part of what people can do when they’re building sites and applications is absolutely force yourself to do everything with the keyboard and 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 say 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 you know, 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.

DF: 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 explains.

PB: I was just about to ask that. That would be immensely useful. At that last piece, as soon as you started talking about testing my immediate reaction is, oh, but you know, budget and time scales, 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.

DF: That’s the thing, you know, like you said, that it’s not and I wouldn’t even say that keyboard testing would be a replacement for to 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 your every, you know, every web developer to do. But I would expect, and really encourage every web developer to test with a keyboard.

PB: Yes.

DF: Test everything with a keyboard to check your heading structure to make sure all your form fields are labeled. I mean, those are all things, you know. 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. But 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 spend , you know, 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 everyday. I would much rather spend that fifteen hundred dollars on testing with real people for certain 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 you know, that shows the value that you’re going to get out of working with them.

PB: 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. And I’m really said hey we need to be talking about accessibility on the show. And you’re right. And certainly, there’s things, a lot more that I can be doing without necessarily huge amount of more work either. It’s just thinking about these things more than anything else. Isn’t it? Very useful.

DF: Absolutely. I mean, that’s good. It all starts with awareness, right?

PB: Yeah.

DF: So I think that’s,that ‘s a big part of this.

PB: 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?

DF: That sounds fantastic.

PB: Alright, thanks very much for your time, Derek.

DF: Thank you, Paul.

PB: Talk to you soon, bye bye.