Think Vitamin Radio: Episode #3

Recorded: Monday 1st March 2010 Broadcast: Thursday 4th March 2010

Keir: Welcome to Episode 3 of “Think Vitamin Radio”. My name is Keir Whitaker. I’ll be your host for the next 30-odd minutes. I’m joined this week by two of my colleagues from Carsonified, Mr. Michael Kus

Mike: Hello everyone.

Keir: And Mr. Greg Annandale.

Greg: Hello

Keir: Ryan is on holiday so Greg is joining us this week.

Mike: Good to have you with us, mate.

Greg: Thank you.

Keir: For those who may not have met Greg before, he’s a talented front-end developer. He’s now handed me a 5-pound note. He’s been working with us for about 8 or 9 months, doing event tech and quite a bit of site development, JavaScript, jQuery, that kind of stuff, so he’ll be chipping in on that side of things. In Ryan’s absence, we’re not going to touch on web apps this week, or web business. We’re actually going to focus on web accessibility, which is a topic that we’ve been learning a lot about, or in particular, Mike’s been learning a lot about over the last month or so. Let’s kick off. Mike, you went up to Warwick to meet the guys from AbilityNet, a couple of weeks ago, in the snow. Why don’t you give us a quick overview of the kind of things that you looked at and maybe start talking about some of the big themes that you covered.

Mike: I went up to see a guy called Joe Chiswick, who is an accessibility expert and he basically MOT’s sites; he looks over sites and checks them out for accessibility. Carsonified want our stuff to be accessible and I think it stems from people pointing things out to us on Twitter, “This doesn’t do this; this doesn’t do that.” We want to get to the bottom of it all and make sure we’re producing accessible work.

Keir: Before you go on, what is accessibility? How are you defining it for the rest of the conversation, what does web accessibility mean in your eyes? Greg, what do you consider it as?

Mike: I think it’s a site that can be accessed by everyone, essentially.

Greg: The site content is what we mean.

Mike: We can use it, someone with limited sight can use it, or someone who might be using just a keyboard to access the site can use it.

Keir: So I guess it goes beyond what a lot of people associate with accessibility, with things like screen readers; it goes way beyond that.

Mike: Yeah, it goes beyond that. It’s not just screen readers. There is more to it. We went over a lot of that stuff in the meeting we had. I think what was interesting about accessibility is people talk about accessibility; no one on the web and on Twitter talking about it, no one would claim not to know about it because it’s almost taboo not to know about accessibility. I’m definitely not an expert in it, I wasn’t before, and I’m not now. But the great thing is having spent a day with Joe at AbilityNet has opened my eyes to what you can really do to make your site accessible. The good news is it a lot of it is just common sense. One thing that makes it difficult is there aren’tobviously there is a big thing called “WCAG”, it’s just initials.

Greg: Web Content Accessibility Guidelines

Mike: Yeah, exactly but that’s a big, chunky document. It’s not realistic to sit and refer to that all the time. What I went up to speak to Joe about was to get a real-world, usable compiled list of stuff that I could go through from start to finish to make sure that all the work that I produce is accessible. It’s a real-world list, something that is actually usable, understandable, in everyday works.

Keir: Greg, you’ve worked a lot of freelance work in the past. Do clients care about this kind of stuff?

Greg: It’s kind of a variety. There are often clients that don’t necessarily appreciate accessibility and it’s really your job to educate them to explain why it needs to be done and how you do it. It’s just being transparent about it, and allowing them to understand and appreciate why it’s worth just that bit of extra effort. As Mike said, it’s not a huge thing to do. It’s mostly common sense and you should really be building sites in this way anyway. It’s not like you make a site and then the next layer is to now make it accessible. It needs to be part of your workflow. I’m not trying to make it sound like a bolt on or anything. There are other clients that have heard that they ought to make their sites accessible and they say, “We need to make it accessible,” but they don’t necessarily understand exactly what that means. Often, they’ll use the example of a screen reader just to illustrate what they mean, but beyond that they don’t necessarily understand the full meaning of accessibility.

Keir: Mike, what were some of the main takeaway points that you got from your day?

Mike: I think the first thing Joe and I looked through were our sites. It was cool because we found out that there were some problems with it. We went through them one by one, but essentially, they were pretty accessible. The main things from the beginning were just really to look at your site and make sure it makes sense from and HTML point of view. When you start off at the top of the page in the code, you want to make sure to add information that’s basically laid out in a way you want people to read it. Obviously, the visual on-screen app, you could be positioning things anywhere. You have to make sure it’s in the right order in the code and make sure you correctly use headings throughout; you don’t skip headings. Something that jumped out to me was people tend to use different level of headings. I was looking through some sites and people start to use the H4′s and H5′s, lower down the page. Really, something that Joe explained to me that was very useful was a parent/child relationship between headings, maybe your main heading, your H1 on a page and an obvious single heading. Your next level of heading would be an H2. You don’t actually have to leave that H2 heading unless it’s a subheading. If your H2 heading is about kitchens, and the H3 is a sub of that H2, you would do it. But if you’re changing the subject completely, you’ll just use another H2.

Keir: I think the example you gave me was things like footers. Often, sites will mark up a footer, maybe saying “Contact me” and that may be an H4 or H5. Actually you’re saying it should logically be an H2.

Mike: Yes, because its next relatable piece of content, it was the H1.

Keir: Does this have knock-on effect in how the assistance devices, such as screen readers, interpret the page then?

Mike: No it will still get to that heading in the order you get for the code, but what it does for the listener if they’re listening to that is when they hear heading level 2 for example, they may have already heard some heading level 3 or 4 because it was related to the content above. Here at level 2 again, they know they’re in a brand new section again, which is useful for them to know it’s a new section.

Greg: So they hear a heading 3 and realize they haven’t heard the heading 2, “Have I missed something?” It’s poor markup.

Mike: If you’re working quickly it’s easy to lose track of this sort of thing. That was something very simple but very useful.

Keir: Did he touch on what you should use an H1 for? I know that’s one of the big debates.

Mike: It is; people have different opinions about it. Joe’s opinion was basically the H1 should closely relate to the page title, the title in the head. If it was a schedule on one of our events pages, it might be a Future Web Design schedule. It might say “Schedule Future Web Design Day One”. Basically, the rule of thumb is it should closely relate to the page title. I don’t think just having the logo as H1 on every page is something to do.

Keir: Which we’ve all done, most probably, in the past. What were some of the other areas you touched on? I know we’ve spoken previously about the use of extra markup that’s often used for presentational purposes, such as spans, that kind of stuff.

Mike: I was really interested to know more about that because it’s the sort of thing that flies around in the “webisphere”.

Keir: Webisphereanother new word from Mike.

Mike: It does, I’ve used HTML to do presentational stuff loads of times.

Greg: Essentially I guess what you’re talking about is just wrapping divs, for example. You need that extra element to hook the image to.

Mike: Yes, doing that sort of stuff, or even putting spans inside headings to color a certain section of that heading a different color. People say you can’t put spans in things. The truth is; it actually doesn’t affect accessibility at all because these screen readers are clever enough to ignore all that. You can wrap a span around every letter in a word and it won’t make any difference. The only think to make sure of is that you don’t display:none because some screen readers then don’t read it. That’s something to avoid.

Keir: While it might make your life hellish to maintain it, it doesn’t actually have any knock-on effect for the screen readers?

Mike: No, it’s a different issue.

Greg: It’s a best practice thing as well.

Mike: I’m not saying to go and write crappy markup, you obviously want to write as lean and mean markup as possible. It’s not really an accessibility issue.

Keir: What else did you talk about while you were there? What were the other big things?

Mike: We used websites with screen readers and we used websites with voice recognition to see how easy it was to use a site like that, to basically experience what it’s like to have to navigate a site. For example, with the voice recognition, it’s really interesting because you want to get to a link thats “two-thirds on the right hand side of the page”. How do you get there? You bring up this mouse grid and you go “mouse grid” and suddenly the screen is divided into 9. The browser is divided into 9 and they’re numbered 1 to 9 or something. You select a square in that grid and it zooms into that square, divides that into 9

Greg: It just continually subdivides until you’re at a resolution where you can -

Mike: And then it starts numbering the links within a square, and you go “3″ and it will open that link up. You can do it pretty quickly. It’s really useful to see that. Something else that was very interesting was people who tab through websites, so you tab for your links. This is interesting, like a tip Joe gave me; if you’re giving a link a red hover state, goes black to red, also do something with the focus as well so if you’re tabbingif you’re tabbing for a site, subtle rollovers and subtle changes aren’t great to try and keep track of because the cursor is darting around the screen. You should create an obvious focus, and active state. If someone is tabbing through they can do it quickly and see where the cursor is as it tabs through links and headings.

Keir: Do you still have to do the old “love/hate” ordering of those? Does it linkis it a hover active? Back in the day I remember that’s how we did it. You do that, Greg, don’t you?

Greg: I didn’t quite have the same way of remembering ordering, I’ll have to say. I haven’t come across that one before, but just coming back to the focus and outline; I believe Patrick Lauke has written an article for 24 Ways, the most recent one that covers in detail the focus element and the active element. Sorry, I’m saying element but I should be saying attributes. He discusses what effect that has, especially on the active attribute, for users that aren’t typing. It can have some unwanted consequences that he discusses, and he gives you some ideas of how you can manage that. That’s certainly worth checking out.

Mike: Another interesting thing is that Ryan was always asking me if that’s contrasted enough. Contrast is an issue but what’s interesting is it’s an issue for partially sighted people as well as people who have color blindness problems. AbilityNet have a style sheet setting for dyslexic users. If you can use very high contrast, that can actually cause problems, cause confusion. It’s interesting to know.

Keir: How do they solve that problem? Do they have links where you can invoke a different style sheet, depending on your requirement?

Mike: AbilityNet still has three little buttons at the top that you press. There is a high contrast, the standard version, and a low contrast version of the site.

Keir: Just before we move on, maybe you could explain a bit about what Joe was saying about titling of images and links and that kind of thing, the old text or the title text and links? I know we talked about that.

Mike: I was asking Joe about what is the right way to go about writing all the text. For example, if you’re using a link and it’s an image, it can be confusing because you could easily write the input on the images, like “man on beach” or something like that. Really, if it’s a link, you want to be describing where that link goes. For example on our site, we’ve got a link that’s an image link of a person’s face to their Twitter. Let’s say it’s their Twitter page, so you know where

Keir: So make it quite descriptive.

Mike: Yeah, describe where it’s going and not describing what it is. If you can get up an image of a tree, but it goes to Twitter, if you say “tree” it’s not very helpful to that person.

Keir: You’re going to be writing up some of your findings and doing some demonstrations between the blog

Mike: Yes, I’m going to write up a checklist for us so we can follow through. It’s something we’ll learnI’m sure we’ll discover better ways of doing things and people will suggest better ways of doing things. It will be a good start, a checklist that we can follow. I’ll be writing up my findings in a post on “Think Vitamin”.

Greg: I think it’s important to follow checklists like this, as well. There are online tools that check the accessibility of a site but they really don’t do the same job because all they’re simply checking for, for example, is things like MTL attributes or images. What you really need to be checking for is the content in the attribute. I guess that’s what you’re talking about, the semantics of the alternative content you’re providing.

Mike: Earlier on we were talking about how it all stems from common sense, really. If I create a logical structure, logical heading structure. It’s almost like we were talking the other day about it being fashionable to have this skip link thing at top. You should still do it basically. It’s not redundant. It doesn’t have to show in the page but you should really have a “skip to content”. If you had some important information in the footer, for example, you could have a couple of -

Keir: Yeah, you said like “skip to contact info” or something like that.

Mike: Exactly, “skip to content” or “skip to contact”. There is no point to making that list too long but a couple of things maybe.

Keir: The key elements.

Mike: It doesn’t have to show in a page. The accessibility page you can create, as well. People who have an accessibility button, which should probably be near the top of the page because if someone is wanting to have a look, if you went through all that detail to make your site accessible, you may have added a few nice touches that you want to tell people about, then you might as well have that near the top so they get to that quickly, rather than having it in the footer for them to tab through everything before they find an accessibility page.

Keir: Sure, so we can expect that on the site in a couple of weeks, maybe?

Mike: Yes

Keir: Excellent, so moving on we’re going to talk a bit about web fonts. This stems from the announcement that fontshop.com are now licensing some of the most popular fonts for use on the web. The interesting thing for me is the fact that they’re offering up without protection against theft on the web. They’re there and you can shove them on your server and link to using the @font-face directive. What do you think about web fonts and the fact that they’re going to be freely able to download in the same way that someone’s image off a website? Do you think we’ll see a proliferation of web font theft?

Mike: I think it’s inevitable. You hope it’s not going to be the case but you’ve got to be realistic and look at how the music industry has been battling with that same issue. I don’t anticipate it’s going to be anywhere near the same scale, but it’s something they need to think about. Platforms such as Typekit obviously have methods to attempt to solve this issue. I think it’s going to be interesting whether the font foundries embrace Typekit and similar services or whether they try to start their own. It’s interesting to see where it’s going to go.

Keir: For those people who may not have heard of Typekit, can you give us a quick overview of what the service does?

Mike: It’s a way to embed fontsthis is licensed, whether freely or commercially licensed web fonts, into websites. The general premise is you sign up to an account and then you have a certain amount of sites that you can use Typekit on, depending on your account. Then there is a library of fonts. I believe there full library is just over 400 fonts that you can then choose to use on your site, however you see fit.

Keir: That requires JavaScript, right?

Mike: Yes

Keir: Does it require browsers that support that font face as well?

Mike: Yes

Keir: We thinkso it’s modern browser technologies required.

Mike: Yes, it’s a distribution mechanism rather than displaying technology.

Keir: What’s interesting for me is that FontShop and maybe other foundries that start offering web licensed fonts; they must have done the math to actually see it in their interests to license them in this manner.

Mike: Sure, you chose the example of Din earlier when we were looking and that was $384 for the collection as web licensed font. If you look at a yearly Typekit, which is $50, there is obviously

Keir: I think they’ve got an offer where you can get the developer package for $49.99.

Mike: That’s a pretty big disparity of course.

Keir: Mike, do you think this sort of proliferation of all these fonts on the web is a good thing?

Mike: Yes, it’s great.

Keir: Are you going to use something other than Helvetica?

Mike: Yes, I said to you earlier that I came to web design from print, where this wasn’t an issue. You could use whatever font you wanted as long as you had it. The funny thing is; this talk about who owns fonts, and stealing fonts and stuff, it’s still an issue in print because I used to copy fonts off people and they used to copy fonts off me.

Keir: We have to edit that out there.

Mike: I was a young designer; I didn’t realize you had to pay for fonts. Obviously it makes a lot of sense now.

Keir: And you’ve come back and bought all those fonts.

Mike: I have. Actually, I have gone back and bought some fonts, but I think it’s going to be really cool. It can’t be a bad thing. I don’t think like you were saying earlier, it’s going to be a problem that people are going to be overusing fonts, having ten different fonts on a page. I don’t think that will be a problem. I think that will be down to peoples’ design skill and they’ll just be clever enough to keep it subtle, and use the type well.

Keir: I think there are a couple of other sites that we looked at while we were searching this, fontsquirrel.com.

Mike: fontsquirrel.com was something I came across a little while back. It essentially offers commercial use free fonts. These are fonts that are licensed to use on the web so you have permission to use the @font-face directive to serve them up. They’ve got a great array of fonts. Looking through, there are 25 styles of fonts and each has between 20 and 70-80 fonts within that style. There is a great array in this and there are some quality fonts there.

Keir: They’re definitely worth checking out. I think we’re going to see a lot more in the next year to 18 months about web fonts. We’ll keep you up to date on those, or Greg will, and we’ll talk more about those later. What else have we got coming up? I think we’ve got a couple of announcements. We recently launched Future Web Apps Dublin, and that’s your event Greg. Why don’t you tell us a bit more about what’s going on there?

Greg: It’s May 14, on a Friday so it’s a one-day event. We’ve got some great topics. We always have great topics. We’ve got Rafi from Twitter, talking about geo-location and your web app. Simon Wardley is consistently a great speaker.

Keir: He’s spoken for us a few times and he always delivers great stuff.

Greg: We love having him speak for us. We’ve got Christian Heillmann from Yahoo talking about some of Yahoo’s developer tools. Mike McDermott from FreshBooks.

Keir: Mike’s session in Miami was fantastic. I sat at the back of his workshop as well, which was how to build a web app business from A to Z and it was fascinating stuff. I’ll be writing that up soon. Mike’s definitely good value, definitely worth seeing.

Greg: Absolutely, and we’ve got Relly Annet-Baker as well, talking copy.

Keir: She’s great. She’s done workshops with us a number of times and is always in good form. That’s in Dublin on May 14, which leads nicely into a weekend so people can definitely make a good little trip out of that. We certainly will. We’re also going to be announcing some details of our new online conference for HTML 5. Greg is working on that at the moment and we should be announcing full details of the speakers in the next couple of days. Where will people be able to find out about that Greg?

Greg: That will be at carsonified.com/online-conferences/html5.

Keir: Very good, and that follows on from the CSS3 conference which is taking place this month. That’s all we’ve got time for this week. We hope you found the chat about web accessibility useful and as I say; Mike will be writing up his checklist on the “Think Vitamin” in the blog, in the next couple of weeks. Until then, we shall say goodbye.

Mike: See you then.

Greg: Cheers