This is the transcript of a podcast recorded on February 28, 2013 between Chris Coyier and Dave Rupert, hosts of ShopTalkShow and Derek Featherstone, accessibility specialist, author, and speaker. It was recorded over Skype and posted as Episode 58 of ShopTalkShow on March 4, 2013.

Interview Summary & Table of Contents

We talked about a lot of different topics on this podcast, and I think most of it made sense! The podcast was sponsored by Converge SE and the Responsive Web Design Summit. Here’s the topics we covered:

Chris Coyier: Hey everybody thanks for listening to Shop Talk Show this week.

There are a couple of sponsors I want to mention at the top of the show. One of them is a conference called Converge SE in Columbia, South Carolina this April 25th through 27th. You can check that out at

Environments for Humans, our long time sponsors, are doing their Responsive Web Design Summit, which is an online summit April 16th through 18th. Check that out at We’ll tell you a little bit more about it later in the show, but for now let’s kick things off.

Dave Rupert: Hello, and welcome to the Shop Talk Show Sound Effects podcast, all about web design and development. I’m Dave Rupert, and with me is Chris Coyier.

Chris: Hey, everybody.

Dave: Today we have a special guest, Accessibility Expert Derek Featherstone.

Derek Featherstone: Hello there.

Dave: Thanks for coming on the show.

Derek: Thank you for having me.

Dave: We really appreciate it. It’s always good to have somebody who’s a specialization pro in their field. For those who don’t know you or don’t follow you or stuff like that, can you maybe tell us a little bit about what you do, your life, your work, stuff like that?

Derek: Sure. I’m Derek Featherstone. I am @feather on Twitter. I’m an Accessibility Specialist with a company called Simply Accessible.

We’re accessibility specialists. What we do is we do our very best work to try and make sure that any site that we build or applications that we build or that our clients are building are as accessible as they possibly can be to people with disabilities and focusing on not just meeting technical compliance requirements, but actually trying to up the game and helping people focus on user experience for people with disabilities so that it’s not just, “Oh, this is passable.” It’s more like, “This is actually an engaging and easy to use experience for people who have a variety of disabilities.” That’s our entire focus.

Dave: That’s beautiful. We rarely hear it talked about in that way. It’s usually more like, “What can we do?” it’s very technical specific stuff to get you there towards accessibility, but less so on the, “Can we make this a beautiful experience?”

Derek: We find that quite often, that people know that it’s something that they need to do, but they’re not really familiar with accessibility and how it works so they often look at it as part of quality assurance and QA checks and things like that. It ends up being where there are a lot of technical components to accessibility, but we’re big believers that it’s just as much design as it is development.

Chris: I’d say that the average Shop Talk Show listener is probably, just through my own eyes of this is how I am too, is that I get it kind of. It’s not my strongest point is building accessible things, but I’m kind of in this tweener stage of wanting to know more and trying harder about this stuff, but ultimately being a little confused by it and not sure.

Sometimes you stick your toe in the water and write a little bit about it, but kind of get swarmed with people who know more than you or have different opinions on how it all goes down. I’m not sure where I’m going with this exactly, but I’m just trying to give you some background on it.

Just because this is a front end development kind of show, we’re probably end up talking about some technical things, but hopefully you can add your perspective.

Derek: That’s totally fine. Our team has a lot of experience with both the design and the dev side of it. I used to be a high school teacher, and then I left that world to start my own company. The first gigs that I got were all development related gigs, and part of the reason that I started doing development was because I was teaching people about the internet and how to build websites and web pages and using a lot of the techniques.

I just felt like I don’t want to be that person who only knows how to teach people how to do stuff. I want to actually be able to create production quality websites on their own, and then use that experience so that I’m actually not teaching people just because I read a book and know some specs, but I want to actually teach from my own experiences.

I have that dev background as well, both front end and back end. We can geek out on dev stuff, absolutely.

About Simply Accessible

Chris: Sweet. Simply Accessible is a consultancy, I guess. You said you guys build apps for clients, and then you also help clients fix their own applications? What’s the breakdown there? Is it 50/50 on what you guys are contracted to do?

Derek: It really depends. Even when we’re working with clients, one of the things that happens, if they’ve contracted us to help them with their app, what often ends up happening is we’ll get to a certain point where they say, “You’ve given us this recommendation, but we don’t know how to do this. We’ve tried this, but we can’t make it behave the way that you’re saying it needs to behave, so can you do this for us?”

Sometimes we’re building things on their own. Other times we’re actually just integrating ourselves with other people’s teams and helping them build things or helping them design things. We’re all accessibility specialists, but we have designers and developers on the team who all have that really high end design experience or hard core dev experience. We’ve just kind of up skilled everybody with accessibility.

When we’re talking with people and working with them, we’re able to do the kinds of work that our clients are needing of us, but we’re also able to add that accessibility layer to it. That’s one of the ways that we get involved in terms of actually building apps ourselves.

There are other times when somebody does come to us and we would love a website to be built and we know it needs to be accessible, so can you guys take this for us and run with it? We do that, as well. We’re kind of a full shop, able to do everything. I would say probably 80% of the time is spent doing consulting work for our clients and maybe 20% is people coming to us and asking us to build sites or applications for them.

Dave: Cool, awesome. That’s a good mix.

Thanks again, Derek, for coming on the show. Let’s jump into maybe some news and links. Does that sound good, Chris?

Jason Kiss on ARIA tree views

Chris: Yeah. I’m not even sure how I first became aware of this site or when I put it in my RSS reader, but I was just kind of going through articles the other day and there was this mega article that came up that was all about accessibility that looked pretty good from the Accessible Culture blog. I guess that’s Jason Kiss. Do you know who that is, Derek?

Derek: I do know Jason.

Chris: Okay, cool. The article is called “Not So Simple ARIA Tree Views and Screen Readers” about the trouble of role = tree, a tree view being like nested navigation. It was all about that. Did you happen to see this one?

Derek: I didn’t see that one, but I know Jason’s work pretty well. I didn’t dig into that one.

Chris: Can you summarize Dave, maybe?

Dave: He kind of just summarizes the tree view and what it does and he builds an example test case, but then he kind of runs it through all the screen readers. Maybe you can clarify, Derek, how browsers and screen readers interact exactly. Each one kind of had their own unique problems, so he tried four different options as to what to do here. Messing with tab index even, and then even doing display none and ARIA Labelled-by. It ended up being this kind of somewhat long, and it seems difficult to successfully pull off role = tree.

[reference point 0:10:02]

How Screenreaders work

I guess that’s kind of a two part thing. Derek, I guess maybe for listeners who don’t know, you can probably explain this a lot better. How do screen readers and browsers interact? Do you think we should be marking up all of our drop down lists in role = tree?

Derek: The first part, at a really high level you basically have on the computer within the operating system, there’s an accessibility API. That’s kind of the bridge between assistive technologies like screen readers and the browser. We write markup and that gets interpreted by the browser, and that DOM is then exposed in some way, shape, or form through an accessibility API that’s on that particular platform whether it’s Mac or Windows or Linux. They all have different APIs.

The assistive technology taps into that API to interact with the website. They’re all kind of different, and screen readers are a very different beast than voice recognition software. They all have different ways of interacting.

If you’re using a screen reader, it’s going to depend on the screen reader that you’re using whether or not it looks at the dom directly via the accessibility API or some of the screen readers that are sort of popular, on page load they create basically this screen reader buffer where it stores that initial state of the page and then that buffer is what gets exposed to the assistive technology through the API. They’re basically taking a snapshot.

That’s on Windows based screen readers. They don’t all work like that, and even some of the most popular ones are kind of changing the way they do this. One of the problems when you create a snapshot is that it gets out of sync with the dynamic stuff that we do on the web today. We run an Ajax call and the content’s updated, but what ends up happening is that that snapshot that’s in the screen reader’s memory for lack of a better term is now out of date.

Dave: Are you kind of anti the ones that do the snapshot thing? Is it better to support the …?

Derek: Full, real time inspection of the dom is actually much, much better. It’s not perfect, but it’s definitely much better. The ones that create this buffer, it’s kind of just the way they were originally built.

One of the things that happens with most software, and I’m not saying that this is definitely the case, but one of the things that happens with a lot of software is you create a version one, and then you move to version two and three and four and you keep moving on and you just keep adding more stuff in without ever really doing a complete re-write from scratch. A problem that might have been in existence in mark one version screen reader is something that gets patched, but it doesn’t necessarily address the real need. It’s something that keeps getting added to over time instead of actually just ripped out and something new put in.

I think that’s not just a screen reader thing. That’s just software development in general.

Dave: Absolutely. As I understand this a bit, if you’re talking about some specific feature, first the browser has to support whatever feature that is. Second, there’s an API, so there needs to be an API to support that feature. Third, then the screen reader needs to support it. It’s never as simple as just this screen reader supports that, right? It’s kind of layered.

Derek: Yeah, exactly. There are a lot of different layers in it and one of the things that I think frustrates developers who get into this kind of stuff is that it seems like there are inconsistencies.

Taking a look at Jason’s article on tree views, one of the reasons that we have to test across all these different screen readers with assistive technology is just that there are different interpretations. This is no different from browsers, even. If a browser makes a particular interpretation of the spec and they implement it in a particular way, then that has a knock on effect in the way that it either does or doesn’t get exposed to the screen reader through the API.

There are a lot of moving parts and a lot of different layers. It’s unfortunately just kind of the way it is. That’s why I know when we do testing, we have this big matrix that we use to say, “We’re going to test in this browser with these pieces of assistive technology.”

Again, this is pure technical testing. It’s not even user testing. We usually get to that later down the road. In terms of the technical testing, we basically create a matrix that says, “Here’s what we’re going to test this in and see exactly what’s going on.”

In some cases it’s a bit of a nightmare.

Chris: You get as much green as you can on that matrix.

Derek: Yeah, and it gets a bit tedious at times, but you want to make sure that you’re covering things because the organizations that we work with will say we want to make sure that we support, just like we have browser support matrices for browsers and have greater browser support, people want to do similar things with screen readers.

They’ll say, “The current version of JAWS is version 14, so we want to support version 12, 13, and 14 and we want to support on the Mac platform. We want it to support the current version of Voiceover. On Windows, we want it to also support a free screen reader out there called NVDA. We want it to support that, as well.”

>We get into these things where it’s not just that assistive technology support, it’s those assistive technologies in different browsers. We find bizarre bugs all the time that just don’t make sense, but there’s something in the way that the assistive technology is interpreting what’s being exposed via the API that happens to live in the browser.

Dave: Yeah, hence the matrix.

Derek: Exactly.

Dave: One axis of the matrix is the assistive technology and one is the browser that that assistive technology is being used in.

Derek: Plus, we just wanted to have a tool that we could call The Matrix.

Chris: Priorities.

Dave: That was awesome. That was a really good explanation. I guess back to role = tree, is this something you’re using in your day to day? Is this something you recommend? Is it problematic enough for complicated enough that you just kind of don’t?

Derek: We don’t use trees unless we’re actually really trying to create a true tree.

Dave: Like a file browser in a code?

Derek: Exactly, something like that. If we were to do that, then we would go ahead and make this work like a tree and we would implement some of the ARIA that’s there. I’ll be honest too, one of the things that we focus on, we’ll do the testing and we’ll put it together and Jason is great at going through and creating test cases and things like that. One of the things that we always try to keep in mind is that ARIA is pretty new technology, even though it’s been around since 2005. There are still improvements and implementations that are being made and it’s not a bulletproof solution, even though it’s designed to be this bridging solution. If you can’t rewrite an application from scratch, and we don’t have a tree control in HTML 5. Maybe there will be in HTML 10 or whatever, who knows? We don’t have those things, so we need to recreate them with ARIA.

ARIA doesn’t work everywhere

The only problem with that is that it relies on technology that’s not supported everywhere. People are quite often surprised when I tell them things like that ARIA doesn’t really have support in voice recognition software. If you create something with ARIA and expect a certain type of interaction, it may work fine with some particular screen readers, but it’s probably going to have no impact on voice recognition software.

We’re always trying to balance. Our position on ARIA is that we should use it, but we always need to have, going back to our progressive enhancement approach, ARIA we talk about HTML and then CSS and JavaScript. We look at ARIA as that other layer, but we want to make sure that we always have a working solution that’s as good as it can be before we layer the ARIA on.

[reference point 0:20:09]

Chris: A working solution would basically be for a sighted mobile developer, like tab keys and enter keys more or less, right? You should be able to open a control with an enter key or manipulate it. Is that kind of what you mean there?

Derek: Yeah, that’s part of it. I’ll give you a really simple example. You can turn a link into a button for a screen reader by giving it a role of button. A screen reader is going to treat it as a button if it supports ARIA, but if that screen reader didn’t have ARIA support, and most of them do now.

There is that, but if you let that be announced to a screen reader as a button, there’s this particular type of interaction that a screen reader user is going to want to have for that. They’re going to expect to be able to click that button with the spacebar.

The spacebar or the enter key will activate a button, but one of the problems that we often see is somebody will take a link and they’ll add role = button, but they won’t do anything to take care of the spacebar. They don’t have a click handler on there or a keyboard handler on there that traps for the spacebar so that it fires that button’s click event when the spacebar is pressed.

We look at that and think if you’re using ARIA to create a button, a better solution is to just create a button in the first place. Pick something, let’s not create things that rely on ARIA, particularly things like trees. Those are pretty complicated structures. You can recreate a tree. People have been doing it for years with divs and spans. There are certain things you need to do to kind of make sure that that tree is as tree like as it can be even without ARIA.

The things that we do with ARIA are to say this thing has this particular role, it has these properties, and it has this state. Those are the three basic things that ARIA gives you. We use those as much as possible, but we also try to find other ways of doing those things. If you think of a tree view, beside each little folder you have a =/- icon for expanding and collapsed.

You can give that tree item, you can say it’s ARIA expanded = true or ARIA expanded = false, and that will tell people what the state is, but only if they have an ARIA capable browsing scenario. Whenever possible, unless we know we’re dealing with a very specific environment where ARIA is going to be 100% guaranteed to be there, we embed a lot of that collapsing and expanding. We embed some of that state information in the ALT text of the +/- icon so that somebody who doesn’t have ARIA still gets a clue as to what’s going on there.

That’s something that is quite often missed when you’re using ARIA. People make the assumption that this ARIA is going to solve all of our problems, and it is pretty good, but it doesn’t have good fallback right now. I always like to say that ARIA doesn’t absolve us of our responsibility to use the most semantic and meaningful markup that we can in the first place.

Chris: CSS developers think you have it tough. Triple it. Cool.

I’m just looking at our list of news and stuff to go over and it looks like we’re at a bit higher level than some of the rest of this news. I recently had a post that I published [Navigation in lists: to be or not to be]. I write mostly about CSS and it was about the NAV tag in HTML. Just NAV. I had heard a presentation or mostly read people’s articles that they were at this presentation of this completely blind man who was talking about web development and markup and navigation specifically.

He made this very strong point. He felt strongly that you shouldn’t use lists as navigation. He was like, “It’s too verbose. I don’t like it. You should just use NAV and have a bunch of links inside that NAV tag.”

I posted about it and posted some links to that article and I said, “Isn’t this kind of interesting? It’s been kind of weird in HTML 5 anyway because we used to have lists for NAV and now we have to wrap that again in a NAV tag. It seems like we have more markup than we used to have less of. What do you think about that?”

It sparked quite a conversation. This was one of those moments where I was like, “Wow, the world of accessibility can kind of come down hard on you if you aren’t prepared for it.” It sparked quite a conversation thread.

Weighing it out after that thread had kind of settled down, it seemed like using lists for navigation was kind of a better idea. I’m not sure if you saw it or how you think about that kind of thing. I just put it in here because we have an accessibility guy on. That’s kind of a microcosm of what you do. I’m sure you deal with bigger things.

Derek: I totally remember that article. When I read it, my feeling as I looked through the comments, and this is my experience–it may not be everybody’s experience–there are a couple of different things at play here. There’s personal preference and there’s also performance.

One of the things that people always talk about with screen reader users is do they want to know that an image is there, or do they not want to know that the image is there? You probably saw that on Zeldman’s article [On Alt Text], as well. It kind of had the same kind of feel. Do they want ALT text; do they not want ALT text? Do they want them to be in lists or do they not want them to be in lists? That’s the thing that I love about accessibility is that it’s not that simple.

It’s not just a “you want them in lists or you don’t want them in lists.” The gentleman who said that he doesn’t want them in lists, he maybe doesn’t want them in lists until he finds a situation where it would be really nice if this had been in a list. There’s a lot of preference there.

One of the things that we’ve found over the years is that people will express those preferences and then they get taken to be, “Oh, if it meant that for that person, then it means this for everyone.” That’s kind of taking it to the extreme. Ultimately, if you asked a whole bunch of screen reader users in a survey kind of thing, “Do you want your navigation in lists or do you not want them in a list?” You’re probably going to get 50/50. Some people are going to say yes, some people are going to say no. They’re going to express their preferences and one of the things that we always find is that people express preference, but ultimately at the end of the day it’s about performance.

If they had a task that required that extra piece of information and it was confusing to them because that extra piece of information wasn’t there, then when it comes to performance even though they said that they would actually rather not have them in lists, when it comes to performance it might have actually been better that they were in lists.

We kind of take all of that with a grain of salt in what we do just by understanding that there are preferences. You can’t make that decision. Their preference is going to be their preference and it may be too verbose for them, but for somebody who’s a brand new screen reader user or somebody who’s less experienced, they might actually really appreciate the fact that they’re in a list and it tells them that in that NAV section or in that NAV element, there’s actually a list.

As you move through a list depending on your verbosity, each screen reader has different settings for verbosity. You can say, “I want to hear everything,” or, “I want to hear really terse expressions of the content that’s in there.” Some people will want to hear that they’re on item number two of five. Marking it up in a list actually provides that information there for people who want it.

We tend to err a little bit on the side of caution and use what seems to be the most semantically correct markup. Sometimes that ends up being more verbose than some people might like, but it’s better that you get more information than you want generally speaking than to miss something that might be critical.

[reference point 0:29:48]

Audience question regarding display: table

Dave: Working off of that semantic markup, there’s one thing of describing it with semantics and ARIA roles and then there’s how CSS can affect those things. We have a question here by Michael White. He says, “I teach web design and I have discovered that using CSS as display table is a handy way if you’re targeting IE 8 Plus and other modern browsers to get equal height columns.” That’s something we might want to do visually on a website.

“My question is, is this an acceptable use of CSS display table? I read somewhere that screen readers would interpret the element that has been set with display table as a table. Do you think I should even be showing this to students?”

Derek: I’ve never seen anything where a screen reader actually interpreted display table as turning it into a table. The theory on that is that you have two DIVs that are beside each other and you have a display table on it so that it basically forces them to be the same height. That CSS interpretation as far as I know, and I’ve never seen any cases where it actually did this, that in the mind of a screen reader it turned that into a table in the screen reader’s mind.

Dave: That’s good news.

Derek: That doesn’t mean that it hasn’t happened in some obscure spot somewhere, but as far as I know, I’ve never seen that happen. If you have an example out there or a test case or anything, we’ve never come across it but that doesn’t mean it doesn’t exist. If you have more info on that…

Myths and misconceptions proliferate on the internet

Dave: These are the kind of things that happen in comment threads. Somebody will dislike display table and they’ll be like, “That’s bad for screen readers. No sighted link at all.”

You’ll be like, “Oh, okay. Thanks.”

Derek: It’s the internet. That’s what happens in comments on anything. That’s just kind of the way that it is. You see it in articles all the time, too. I remember seeing an article that spawned me to write an article about CSS. Somebody had actually said in the comments of their CSS, they were doing a menu kind of thing. You mentioned menus earlier. They had something commented in their code, “Use off left positioning for this instead of display none because it’s better for screen readers.”

I wrote a whole article about it basically saying, “Better for screen readers? It entirely depends on the context. We’re also not just talking about screen reader users. We’re talking about sighted keyboard users and people who use other assistive technology.”

In fact, the way that they had created the menu by positioning a sub menu off left, they were actually making it really hard. It was actually easy for a screen reader user, but for a whole bunch of other audiences it was making it really bad because the sub menu was hidden off the screen and as you were tabbing through, the focus is basically off the screen. Somebody who’s using a keyboard but can see the screen has to tab five or six times because the way they encoded it, the sub menu didn’t become visible when its items took the focus.

You’ve created by seeing something where it said, “Off left positioning is better for screen readers,” it actually created a problem for somebody else because they didn’t really understand the impact of it and how it would actually fit in context.

It happens all the time. People see one thing and they’re like, “Oh, this is the way I do it.” I wish it were that simple. There are a lot of cases where it just can’t be that simple because it’s all dependent on how you’re trying to use things and what the interface is and what tasks people are trying to complete.

CSS properties that influence accessibility?

Chris: In general, do you have a rule of thumb about what CSS properties affect assistive technology? I would imagine display none, visibility hidden and off left or position left. Are there any others that might affect assistive technologies that you can think of offhand? Do they tend to not care about presentational stuff like text transform uppercase?

Derek: Some of the things are kind of bizarre. There are bugs in different versions of screen readers. The way the screen readers work are kind of intercepting the screen content. They’re not just browser things, they’re interfacing with the entire computer. I’m being really general here because not every screen reader is exactly like this.

There’s a bug in a version of Window Eyes where if you had something, a DIV or something like that, that had a height of one pixel and a width of one pixel, it would basically mean that it was kind of like the screen reader put this into its code so that it would not read out any of those tracking ad gifs and stuff and spacer gifs.

What ends up happening is people have used other techniques to hide things. People will say, “Clip this to be zero, zero.” There has to be a minimum height of one pixel and one pixel width on an image for a particular version of Window Eyes to actually recognize its existence. People were doing things to hide content from screen readers or to create content that was hidden from view, but specifically read by screen readers by clipping it to zero, zero so that it basically didn’t show up, but it was actually targeted at screen readers but it was not available to those screen readers.

There are all kinds of weird little bugs like that. One of the things that we advocate; people say display none is bad for accessibility, but in many cases it’s actually your friend for accessibility. Ultimately what it does with display none, even though it’s in the presentational layer, it effectively hides that DOM note.

Using display none and then bringing it back to display block or whatever display property you want to use, that actually works out really well from a screen reader perspective in many cases just because there are times when you actually want to hide things. You don’t want them to be available. If they’re not on the screen, why should it be there for a screen reader user?

There are lots of cases where the display property is actually your friend from an accessibility perspective. You have to use it wisely, but it’s something you can actually use in a good way. It’s only a problem if you’re not quite sure how to use it.

Responsive design and accessibility

There are other properties. Some of the things we’re seeing now though that are proving problematic are we’ve been doing a lot of work with some clients on their redesigns and they’re doing responsive things. That’s fantastic because I think that’s great. A lot of people talk about the relationship between responsive and accessibility and that this is a match made in heaven and things like that.

One of the interesting things that we’re seeing is that there are actually some problems that are created by doing things in a responsive way, only because of the way that the page changes. It transforms from we have this particular layout and visible display on a desktop computer. When we’re on an iPad, sort of that medium size, we have another display. When we get down to a phone we have even still another display.

When the display changes, one of the things that we’re finding is that you actually need to take into account what that means in terms of source order. When you change the display of something like a menu for example, you’re actually changing the interaction. If you’re changing the interaction you might actually need a different source order, a different keyboard interaction. There’s a whole lot wrapped up into this that really can cause quite a bit of havoc in terms of how a responsive design actually works from an accessibility perspective.

We’re seeing things like that. We just saw this recently too that animations and transitions can be a real pain for somebody who’s using a mobile phone or a smaller screen device, maybe even an iPad Mini or a tablet. When those transitions and sliding animations and things take up a lot of the room, it actually causes problems with assistive technology that’s running on the phones or on the tablets. The assistive technology on the mobile is kind of working the same way as another layer, that here’s what’s on the screen and I know the position of all those objects.

What happens when you have the focus on a link and then you click on that link? The focus should stay there, but you slide a panel up or down and you make a move with that responsive design to slide it up into place so that this new panel shows up. You were on one link and now you’re on a completely different link because you’ve done this sliding animation and transition.

[reference point 0:40:14]

We just did work with a big retail client here in Canada that has an American site as well. They have a really responsive, really cool design, but those transitions actually really made it next to impossible for somebody using voiceover on an iPhone to use that navigation mechanism at all. It was really kind of interesting to see and something where I think people need to be cautious with the way that we just assume that we have these transitions and these sliding animations, that they’re not going to cause any problems.

If it doesn’t cause a problem on the desktop, why would it cause a problem on a phone? On a phone it’s a different experience. That sliding panel that you have that takes up a small portion of the screen on a desktop actually takes up your entire screen on the phone. That whole screen being animated can cause all kinds of problems.

Dave: It would be good to make a test case for that type of thing so we could say, “Look, here’s a good bad example.”

Derek: Yeah, a good bad example. We’re actually working on that now. I have a couple of other talks coming up. I’m going to do a talk at Mobilism in Amsterdam in May, and it’s all going to be about these kinds of things.

There’s this relationship between accessibility and responsive. It’s supposed to be this match made in heaven, but there’s actually a whole bunch of issues that we need to kind of get out there. I’m going to do that and have a workshop in Ottawa in April, as well, a full day workshop on that kind of stuff, too.

Dave: That will be great. We’ll keep an eye out for that. We’ll post a link if we can.

I have to do a sponsor here quickly. We have Converge SE sponsoring this. If you’ve ever heard of, they have kind of a gallery and links site and interviews and it’s a really great site. The guys behind that, Gene, Jay, and Gio, those folks do this conference called Converge SE in Columbia, South Carolina coming up here April 25th through 27th. Check it out at

They always do really cool conference websites because Giovanni is such a great illustrator. This one is this big Yeti dude at the top. They’ve been awesome in the past. They did that robot t-rex one last time that was so awesome. I’m going to be at it, so you can come and see me, Erin Drapeland, Daniel Burka, Carl Smith, Jen Lukas, past guests of the Shop Talk Show. That would be worth checking out.

We’re sponsoring a track with Code Pen, too. That should be pretty cool. I really can’t wait. Columbia is their capital and they have a really cool capital building. It’s just a nice place to visit in general. I hope to see some of you guys in Columbia, South Carolina April 25th through 27th.

Chris: Those are good guys.

Let’s go on to another question here. This one’s from Rob Deluca. It’s a little bit of a hot drama question here. Derek, we’re excited to get your feedback here.

Audience Question regarding making the web more accessible

“Currently I work as a front end developer for a little agency. I do all that I can to make every website I build out more accessible. I know just how terrible the web is for blind people because my mom is blind. Almost every site she goes to is hard to understand for her. There are missing ALT tags and improper labeling. From what I’ve seen, the worst offenders are Google and Facebook.” There’s the drama right there.

“Facebook makes the screen reader jump around and do funky things a non-sighted person can’t understand. Google’s G+ is actually unusable. The side NAV is named something like image one, image two, image three, etcetera.” That’s unfortunate.

“My question is, what do you think we can do to make the web an accessible place? Right now it really isn’t. Blind people are having a super hard time surfing the web and it’s not because they’re lacking skills, site, or technology. It’s because web developers aren’t doing their jobs.”

First off, have you heard about Google and Facebook being troublesome for non-sighted users or people with other disabilities? What do you think we can do to make the web a more accessible place?

Derek: Definitely, a lot of the big companies, Google, Facebook, Microsoft, Oracle. They have huge web properties and stuff on their hands. I don’t envy them at all. There are always problems with accessibility and I’ve definitely heard of these kinds of problems before. I know people who work at Google who are accessibility specialists who work there. The same thing at Facebook.

There are accessibility teams there that really care that are doing their work to get the job done. I think even the fact that they’re not there in a lot of ways is something that is just kind of reality for any big, I don’t want to say behemoth, but in terms of the size of their sites and their web properties, they’re huge.

One of the things that we should do, particularly if you’re a developer who’s in the know and we shouldn’t have to do this, but I think it’s important for us to do it. Facebook has an accessibility team that’s actually on Facebook and they’re even on Twitter. You can report things to them that there are problems with whatever. There are other things that we’ve done before. Google even uses this strategy.

We see things for sites all the time that are inaccessible and that we know how it should be, so we actually write user scripts, grease monkey scripts, that fix what some of the problems are so that they’re not horrible. There are projects out there where people can actually be part of a community that fixes accessibility issues. There’s a Firefox extension that IBM created that allows people to be browsing the web and to say, “Hey, I have a problem on this page. There’s this unlabeled graphic and I can’t tell what it is.”

That gets submitted, then there’s a community of people who basically say, “Oh, the ALT text on this should be whatever that ALT text should be.” That gets kind of saved in this database and reported, then what happens is when anybody is running this extension, it now automatically fixes that site for them so that it takes into account all those accessibility fixes that are there.

It’s not perfect. It’s something that would give those kinds of solutions. It should never come to that, but the reality of it is it comes to that. At a certain point, there are things that you can do to make some of the pain a little bit less at least when it comes to things like ALT text and images.

Keyboard handling and focus management

Keyboard handling is a really neglected part of enterprise web development. People who know about it get it and they sort it out, but there are a lot of people who just don’t really think of keyboard usage when they’re building things. It causes all kinds of problems for lots of people.

The thing that goes with keyboard interactivity is focus management. When you click on something, where does the focus go? When you click on something with the keyboard, where’s the focus moved to?

One of the biggest problems, and we’ve seen this. I’ve actually noticed this on Facebook. There’s a lot of stuff in Facebook where it creates a fly out. You have your timeline down the right hand side and you’ll see things ticking past and what’s going on there.

If you click on one of those, it will actually show you the fly out of the content that shows you the whole conversation. One of the things that I’ve started noticing on Facebook is that when they do a fly out like that or pop up some kind of a modal dialogue or light box type thing, they’re managing the focus well now such that they bring the focus into that new piece of content that’s been shown.

Chris: Is that the ideal? If you’re going to reveal something new, you should move the focus into that thing that you’re revealing?

Derek: Yeah, generally speaking we want to do that. There aren’t many cases where you don’t want to do that. Ideally, if you can do that with source ordering it means that the next item is going to be the next item in the dom anyway.

When you can’t do that, combining that with focus path management where you bring the focus into that modal dialogue or whatever it is, that actually makes it so that you’re creating a logical pathway through the page for somebody so that they don’t click on something and show a dialogue box and then it takes another 50 keystrokes to get to the dialogue box.

[reference point 0:50:17]

Chris: I could see that being weird with modal pop-ups. A lot of times those get appended right before the closing body tag because historically you’ve had to deal with Z index issues and stuff. It’s better if they’re higher up the dom or whatever, but then that’s nowhere near each other in the source order.

Derek: Exactly. What we tend to do when we’re doing dialogues and stuff like that, if we’re injecting new content or doing something new, we bring that content and we try to find the most logical source ordered injection point. Rather than just doing a document .body.addchild or whatever, we find the right spot and inject it there as much as possible. We want things to be in as logical an order as we can. We want to manage that focus path.

If something goes wrong with the focus path, then at least it’s in the right source order so that it may not work perfectly, but we have that fallback mechanism that says if something happened with the focus and you weren’t able to put the focus in the right spot, at least it’s in the right source order so that you’re not having something in the middle of the page and then something that’s related to it at the end of the page.

Sponsored by Responsive Web Design Summit

Chris: We’ve had so much to say this one. We do have two sponsors this week, the other one being the Environments for Humans, our long time sponsors. They’re doing another conference in April called the Responsive Web Design Summit. I would not be surprised if accessibility is brought up regularly at this summit.

It’s three days. You don’t even have to leave your house. It’s online only. You visit it, and there’s actually a good amount of interaction between the people who attend these because there’s a chat room and you literally watch the person’s presentation right through your browser. There’s a chat room that’s attached to that, and there’s lot of talking and stuff going on.

Check it out at That’s pretty cool. Three full days of that. We have a coupon code for it, 20% off the price of all three days if you just use coupon code SHOPTALK. I think these are kind of loose topics; performance, then strategy, and then technical issues. You don’t have to attend all three days if you don’t want to, but you can and I would recommend it. They’re pretty fun.

Audience question about the minimum accessibility bar

We have time for another one, hey?

Dave: Yeah, we have one more that actually kind of perfectly ties in. It’s an audio question from Kyle Zinter. He called in and it’s a two part question kind of about responsive and then also about accessibility.

Kyle: Hello. I have a two part question. When dealing with accessibility, we all know how important it is, but it’s not always super easy to get perfect. Do you guys have a specific minimum bar that you must reach before being okay with shipping a site?

Also, is part of that minimum bar becoming that the site is designed responsively? I don’t know how many people agree with me, but I really see responsive web design closely tied to accessibility, and in my opinion I tend to put it in the exact same category. Is that crazy?

I love the show, guys. Keep up the good work.

Dave: Okay, so part two I guess we kind of talked about, is responsive tied to accessibility? It kind of is, but then it kind of has problems.

Chris: Minimum bar was the interesting part about this.

Dave: Yeah, Derek, do you have a minimum bar? People in the chat room are saying accessibility is nice to have and really worth acknowledging, but my clients have limited funds and time. Is there a minimum bar before you ship something?

Derek: Our minimum is WCAG 2.0 Level AA. We don’t do anything other than that. Let me rephrase it. When we do our assessments, we say we’re going to assess pretty much everything, WCAG, even including some of the AAA requirements. We report back to them and we give our clients advice, but we won’t give our blessing on something that doesn’t meet the AA standard unless they show us at the same time.

Dave: What is this AA standard? It might be nice to just cover that really quickly. Is there an official standards body for this?

Derek: This all comes from the W3C, from the World Wide Web Consortium. They have a web accessibility initiative which created the Web Content Accessibility Guidelines. You’ll hear it pronounced “wuh-cag” or “way-cag” or “double-you-cag” in different circles.

They’re basically a set of guidelines that recognizes that we’re all busy people and busy developers and designers. We can’t take the time to test with everybody, people across all kinds of disabilities and that sort of thing. They ultimately said we’re going to give people a set of guidelines so that if they don’t have time to test with real people, they at least have these guidelines as a starting point. They’re not the end point, but they’re the starting point.

They have three different levels; level A, level AA, and level AAA. Level A is like this is stuff that absolutely must be done or people will not be able to use your site or your application.

I like to think that AA is there are a whole bunch of things that are going to make it much, much easier for somebody to use this site, and it’s bordering on things that are making the site almost unusable. They might still be able to complete the tasks, but it would be really quite difficult to do so.

The AAA requirements tend to be things that are if you can do this, then you really should, but if you can’t, then you can’t.

Dave: That’s funny. That’s AAA, that’s as high as you can get and it’s still pretty loose.

Derek: Yeah. It’s not loose in that sense. They’re pretty strict requirements, but what I mean is I’m sort of talking about it loosely in this sense that we know that if you don’t hit AAA there are still going to be things that are going to be barriers to people. There’s no question about it. There’s a difference in a AA requirement and a AAA requirement.

In a AAA requirement for example you need to have real time captioning for live events. A AA requirement would be that you don’t have to have real time captioning for it, but there’s a transcript available or that it only applies to recorded events. They’re different levels. They’re still all important, but there are certain things that are kind of pushed off to AAA.

An even better example is color contrast. To meet color contrast requirements for AA you need to have a ratio of 4:1 generally speaking. To meet a level AAA for color contrast, you need to meet a higher standard. You need to have color contrast of 7:1 between foreground and background color.

There are still some people who if you hit AA, there are still some people who are going to have a lot of trouble reading stuff if they have a particular type of low vision. If you can, we have some clients who say we’re AA for everything and we’re AAA for color contrast for just that reason.

Maybe I just made it worse by that explanation.

Dave: No. If my restaurant site is actually a JPEG, I have failed WCAG A, right? If my site is actually a website, I can pass A maybe, and if I have good contrast I can pass AA, but if I have super great contrast I can maybe pass AAA just on the contrast.

Derek: Yeah, we’ll leave it at that. There’s a lot more to it, but yeah, that’s the idea. You have different levels. We always say that we’re going to go for AA. If somebody doesn’t meet AA and they still want to ship their site, then we push a little bit and we say, “You can do this. We don’t advise it. Things are still broken. If you’re going to do this, you have to do it with this plan.”

I know we’re kind of going into a little bit of circles here, but many governments around the world are now saying level AA is what you need to do, and not just for government websites but even for business websites, as well.

That AA requirement, we try not to let clients launch something that doesn’t meet that AA standard unless they’re actually saying, “We can’t do all of this right now, but here’s our work plan to make sure that we address those things that are outstanding.”

[reference point 1:00:27]

Where to learn more

Chris: I guess the next logical question is how can people get to AA standard? How do they start learning about what’s involved in there? How can they get there?

I know there was a post out there that accessibility should be left to the experts, but that’s a very small population based on the number of websites there are. How do people get to WCAG AA?

Derek: I think the easiest thing to do is start with a few sites. There are lots of sites out there that provide tutorials and things like that. There are e-mail lists out there, as well.

The W3C has their guidelines and they have an education and outreach group that puts a lot of educational material out about it so that if you’re learning about accessibility, don’t go and just start reading the spec. That’s probably the worst thing you could do.

It’s the same thing with HTML 5. Do you want to learn about HTML 5 by going and reading the spec, or do you want to actually get in and start doing stuff?

Dave: I’m sure that bums out spec writers.

Derek: I’m sure it does and I’m completely fine with that.

Chris: I feel like if you tell somebody to read the spec, you’ve lost any sort of argument.

Derek: Yeah, absolutely. It’s kind of the exact opposite of what you should do. There are lots of opportunities for people to start learning about this stuff. I think the best way to do it is to check out some websites, remember that it is the internet so not everything is true. You’ll get a sense of what some of the issues are and understand what people need to do.

We have a lot of resources on our website, WebAIM is another great resource. The W3C has great resources in their section, particularly the education stuff. One of the sites that I write for is Web Standards Sherpa, so and I write about accessibility things there, as well.

There are lots out there to do where you can go and read and learn techniques and things like that. One of the things you can do that would have the most impact on you as a developer if you can arrange it is to go to a local college or university and see if you can do a tour of their center for students with disabilities or office of accommodation or whatever they call it at that institution. Just go and sit and watch how people work things. Build a website and go and take it to them and see if they can work with it.

There are going to be a lot of things that you won’t understand right away, but you’ll learn pretty quickly. You’ll want to know why things sound so horrible to that screen reader user or why the screen reader read out the image’s source attribute instead of skipping over it. You’ll learn a lot about how people with disabilities actually use the web. That will give you some really good direction to start solving problems.

I think it’s really about doing things one little step at a time. Find one thing that you can improve, and go and learn about ALT text, learn about heading structure. That’s all semantics, anyway, but understanding the impact that that stuff actually has on people on how they use the web with assistive technology, I think that’s a really good teacher.

There’s lots of reading that can be done, lots of things that are really experiential that you can do, as well.

Chris: Very cool, great. Derek, I feel like we’ve monopolized enough of your time. Thank you so much for coming on the show today. We really appreciate it.

I guess our typical sign off, we just ask guests how they can follow you, follow your business, give you money. How does that work?

Derek: I’m @feather on Twitter and you can find me on Facebook as well. I’m on LinkedIn, I’m everywhere. The company is Simply Accessible and we have all kinds of stuff coming up.

I’ve done a bunch of virtual seminars with Jared Spool and the UIE crew. We’re actually starting our own series of virtual seminars. We have a couple in the bag already on forms and making accessible forms, The Truth About JavaScript and Accessibility, and we have one coming up in March that is Finding Your Way with Accessible Maps. We’re punching on that one and it’s basically to give developers and designers the tools they need to get started with making maps more accessible.

We have a lot of experience implementing maps, so we have that. That’s a virtual seminar. It’s actually going to go live for open registration in about an hour and twenty, at 4:00 p.m. Eastern. You can find all that stuff. Most of the things that we do are in my Twitter stream or we created a company Twitter stream recently, as well, for Simply Accessible. It’s called @SAteaches. Anything that we’re going to do is going to show up there, as well.

Dave: Perfect, great. Hopefully some people will smarten up and start following you guys.

As usual everyone thanks so much for coming out and listening in the chat room, sending in questions and everything. We really appreciate it.

Follow us @ShopTalkShow on Twitter. Buy some t-shirts, Rate us up in iTunes. Just click the five start button, it’s that easy. Tell your friends. Chris, anything else?

Chris: I wanted to mention super quickly that these two conferences are highly affordable. Some people are like, “How do you go to all these conferences? They’re so expensive?” Both the and Converge are both sub-$400 conferences. They’re very affordable, so check those out. There will be a link in the show notes.

Until next time, folks.