(Daniel Steinberg) Welcome to the Pragmatic Podcast for December 19, 2007 featuring Jeremy Sydik on accessibility. [Jazzy Background Music] (Jeremy Sydik) We're not going to get to a point where every user is perfectly accommodated. What we need to do is make sure that we have done the best possible and are ready to help out users if something comes up. (Steinberg) That's Jeremy Sydik. I'm Daniel Steinberg, and this week I'm honored to turn over the reins to Pragmatic Programmer editor Susannah Pfalzer. She interviewed Jeremy over Skype about some of the principles from his book, Design Accessible Web Sites: Thirty-six Keys to Creating Content for All Audiences and Platforms. Susannah begins by asking Jeremy- (Susannah Pfalzer) Why develop Accessibly? What's the benefit to web designers and developers of making their sites accessible? (Sydik) There's a couple of good reasons to do it actually. First of all the legal mandate. Websites that are accessible to the public for commerce or government use need to be accessible. That's part of the Americans with Disabilities Act and Section 508. You obviously want to stay in legal compliance, but there are also a lot of good commercial reasons to do it. First of all it's a very large market and a growing market. It's a multi-billion dollar market now. As we're seeing a lot of technology via iPhones, cell, PDAs, video game consoles that have web browsers a little bit off of what we're used to designing for and accessible design also opens us up to some of those markets. (Pfalzer) How do you recommend people approach accessibility with a view to all these government guidelines and standards that are out there? (Sydik) I actually recommend using them as a guideline and reference. This is about how we write websites and we shouldn't be thinking "oh WCAG section blah blah blah says this". What we need to be doing is thinking, "well okay, if a blind user goes to our website we have this image that's really important and they need to know what that says". The best way is going to be to learn to think accessibly. For a while now...actually its a set of guidelines which are just kind of ten basic rules for how to design web sites. It's more of a here's how to think about it, rather than here are exact steps. (Pfalzer) Do you want to talk a little bit about these ten principles and talk about why they are so important? (Sydik) Two of the principles that I think are most important... One is to avoid making assumptions about your users abilities. You can't assume they have this level of vision, they have hearing, they have this ability to resolve contrast. The other related thing is we don't know anything about their technology. The only thing the web really guarantees us is they can send and receive ASCII text, that's it. So if you've got audio, you need to have some ability to present that audio without relying on your users having audio playback or hearing. If you have video you will need to transcribe. You cannot assume that the user has vision or that they have whatever plug-in you need or whatever level of monitor you're assuming that your video needs to be played on. (Pfalzer) So if you re a developer looking to start developing accessibly where do you start? How do you get set up to do accessible web development? I think there are two parts to that question: how do you get set up with the tools you need and how do you change your mindset to look at development in that way? (Sydik) Actually to start out you don't need a lot. You'll need a couple of plug-ins, things that let you turn the images off and turn the stylesheets off. There are tools out there that will kind of give you an analogue. For Firefox, Peter Krantz has a great screen reader analogue that can be downloaded which will basically just give you a text read-out of what a screen reader would be saying were they to read that page. You'll need the basic color tools so you can start shifting things like contrast control, things that will take your images shift the contrast off and let you see - oh wait a second, this is really off. As far as techniques, there's a lot of places you can start. I would not recommend starting by saying, "oh we've got you know, fifty thousand hours of video let's get it all transcribed and captioned and all that next week." But alternative text is usually the biggest bang for the buck. If you can go through and make sure all of your images that are content based have alt text that will get you further than any other thing, and it takes the least effort to do it. The big thing you'll run into as far as complications are if they're not your images you'll have to start tracking down the original designers and saying "Okay, what is this thing? What needs to be said about it?" Part of it is learning what can and can't be done in a reasonable amount. The related area, this isn't considered a visual area per se, but is actually a very important one are issues of flicker. Flicker comes out as a problem with photosensitivity and certain people can have seizures due to epilepsy when they see certain flashing or flickering patterns, and that's a fairly serious concern. There was a huge concern, well, a few years ago there was a kid's cartoon that caused children to have seizures and more recently some promotion for the London Olympics had the same problem. And beyond the issue of accessibility this is an area where we start to find out as we design our content we have the potential to harm our users. (Pfalzer) We talked a little bit about visual impairments. There are a few other kinds. How about hearing impairments? What do we need to do to make websites accessible for the hearing impaired? (Sydik) That's an area that is important to consider. I don't want to focus too much on the visual impairment. The reason...and you'll see a lot of people talk about accessibility, and it goes right to people with visual impairments. This isn't because we're thinking more about that population necessarily. Its the issue that there's a lot more work to do sometimes because we do in web design think very visually most of the time. When it comes to multimedia obviously that has challenges of its own. When you have somebody who has an auditory impairment you have to start thinking about every sound cue you create, you need to think about audio you present. There are issues of deafness, there are issues of hard of hearing. Hardness of hearing a lot of people don't think about right away when they're thinking about website accessibility and that is very...it could be that somebody is very close to being deaf and you need to have full transcription, it could be that you have somebody who has more mild hearing impairment and they need some sort of visual cue that would represent your normal audio cues. If you have a beep you might want to have a small color cue change somewhere that is obvious to the user or some other sort of notification that "oh, something is happening here". That doesn't necessarily affect the web as much as it does general software. With the web it's usually a bigger issue of making sure that your audio has transcription available where possible. Another major class of disability are mobility impairments. Those are a little bit different to handle because usually mobility impairments are addressed with hardware. I mean your specialized mouse or keyboard analogues and the big thing you need to make sure is that you don't have the little 3x3 pixel button that somebody has to navigate in a field of 3x3 pixel buttons because someone who has a little bit of a shake to their motor control, they might have some issues there navigating your website. We're not going to get to a point where every user is perfectly accommodated. What we need to do is make sure that we have done the best possible and are ready to help out users if something comes up. (Pfalzer) What I'd like to close with is actually having you read the ten principles. (Sydik) Sure. The first is to avoid making assumptions about the physical, mental, and sensory abilities of your users whenever you can. That means you don't know if your user has vision, you don't know if the y have high vision, you don't know if they can see red versus green. You don't know that. You can't assume it. You need to make sure that your content is available for them. The related one, and I mentioned this earlier. Your users technology can send and it can receive text. Images, video, sound, you don't know. You can't assume it. Number three is the users time and technology belong to them. It's not ours. When we take away focus of the cursor, when we bump them to another website, when we change the page and we force a reload, we're taking control of their technology. We need to think of it as we are a invited guest on their system and we need to not overextend ourselves when we do that. Number four is that we need to provide good text alternatives for any non-text content When you do go beyond text content the things that you need to create alternatives for...You still should use widely available technologies. If you're using some plug-in that maybe fifty people on the planet have installed, that by default isn't very accessible. Unless you're doing some sort of research and development, there's really not a good reason to do that. Something that I think doesn't get thought about as an accessibility issue or even as a web design issue is number six and that is to use clear language to communicate your message. You need to make your sites usable, searchable, you need to make them so that they can be navigated. This is a basic usability issue, it's not a direct accessibility issue. I mean it comes up for users when they're in text mode, and it comes up for users who have mobility impairments. It's really important to keep that in mind, accessibility is a subset of usability. If you're not usable, you're probably not accessible. Number eight is design your content for semantic meaning. Maintain separation between content and presentation. It's back to the ability...some users need to turn off your presentation. Its not that you've got a bad presentation, it's not that it's badly designed- it may be perfect, but it may not suit the user at hand so it needs to be able to go away when it needs to. And part of thinking about that we get to principle number nine that you want to think of features as progressive enhancement. You want to take a basic content, add the features that you want so you know that it goes back. And then it will be able to "degrade gracefully" for users who don't want or can't use those technologies. Start with the basics and then you will know that the users who can't use it or don't need it can move away from it. The last principle is kind of our catch-all, although I think it is a really nice catch-all. Number ten is when you encounter new web technologies, apply these same principles in making them accessible. That means the first nine. I cover a little bit about Acrobat and PDF, I cover some Java, I cover office type documents. The rules change a little bit. You may have to go to a different place to do your alt text, you may have to map things out a little bit differently, but the principles hold and, again, I think once you have basic understanding of the principles of accessibility, when you go in to do that it isn't such a change anymore. Its like, well okay, yeah this is Java, yeah we're writing in code, but okay here's the accessibility package, here's where we're tossing in our alt text We know if we put alternative text here we're going to be able to read it. It will take a little bit more work but it won't be jumping into an entirely new venture. [Jazzy Background Music] (Steinberg) Jeremy Sydik discusses the lessons from his book Design Accessible Websites with his editor Susannah Pfalzer on the Pragmatic Podcast. For more information about Jeremy's book, visit the newly remodeled website pragprog.com. You'll find all of our poscasts at pragprog.com/podcasts. And you can join the discussion at forums.pragprog.com. The music for this podcast was composed and performed by Andy Hunt. For the Pragmatic Programmers, I'm Daniel Steinberg.