Second, Hunt Griefers for Fun and Profit

When I chose the title “It’s Not Polite to Flash the Audience” for my discussion on photosensitivity, it was deliberately a bit flip to balance the seriousness of the topic. I had also thought about “First, Do No Harm” but it seemed a little too preachy at the time. Either way, I never imagined that I’d need to think about photosensitivity being an opportunity for twisted minds to physically assault users via the web as happened a few weeks ago. Some [pick any nasty epithet here] decided to post JavaScript and animated images designed to trigger migraines and seizures in users with photosensitive epilepsy. Worse, the message board was located at the Epilepsy Foundation (A full background story, including a description of the attack by an affected user is available at Wired). This goes beyond “normal” griefing—this is assault, plain and simple. Since the attack, there’s been a lot of speculation about who was responsible for the assault and whether they can be caught and, while I’m one of many who would love to have a few minutes with the perpetrator, I’m not very hopeful that the investigation will lead very far. There’s something important that can be done, however, and that’s to get information out there to help prevent things like this from happening wherever possible.

I’ve gotten several requests for more information about photosensitivity since this happened, so I spoke with Andy Hunt at Pragmatic Bookshelf about the issue. Andy reacted similarly to the problem and we’ve decided that, as a public service, we’re going to release Tip 27: It’s Not Polite to Flash the Audience from Design Accessible Web Sites free of charge. Reading back through the tip, however, I wish I had covered the issue more deeply than I did—the tip introduces the idea of photosensitivity and a couple of tools for testing video, but I didn’t go into other kinds of content like I should have. So let’s look at the issues of photosensitivity and user-submitted content like message forums.

The first route of defense for the site developer or administrator is to NEVER allow <script> or <object> content in user posts. This, of course, is a good idea anyway because of the security risks of allowing your users access to these tags. That simple filtering takes care of rogue Flash, Java, and JavaScript, but we still need to deal with with animated GIFs, and here lies the problem. For whatever reason, animated GIFs still seem to be popular in the “still thinking digital watches are a pretty neat idea” parts of the web (with all due apologies to Douglas Adams)—so there is still significant demand for browsers to default to supporting repeated GIF animation. Blocking animated GIFs in user submitted content is difficult at best. The only real options are:

1. Block <img> entirely: This isn’t appropriate to many forums because it unnecessarily limits discourse.
2. Filter the src= attribute for *.gif: This doesn’t really work either. An off-site url to a GIF file can easily leave out the file extension but send a correct GIF mime type.
3. Only allow uploaded images and src= references to your site: This isn’t feasible for technical (do we want to store a ton of graphics for our message boards?) and liability (they uploaded a picture of a giraffe doing what??) reasons.
4. Moderate all image submissions: If you have enough moderators to handle it, this might be possible, but most of us don't and it’s still an impractical approach.

At the end of the day, only the last solution addresses non-animated images with potentially seizure-inducing patterns. As developers, there are some things that we can’t easily address, and it may be that the best we can do is to provide a notice reminding our users that the forums contain user-submitted content which has not been fully vetted for accessibility—this is generally a nice thing to do when you don't have absolute control over the content anyway.

This means that site administrators need to be aware of problem images that appear on their sites and remove them as quickly as possible and users with photosensitivity will need to be careful, as in public spaces, to be aware that certain patterns may show up that could be a potential threat to them.

For users with photosensitivity concerns, there are also ways for you to configure your web browser to minimize your personal risk from animated content:

• Firefox: The Content tab preferences has checkboxes for enabling or disabling Java and JavaScript. The turns off Flash while leaving placeholders that allow you to start the content if you wish. Changing the animated GIF settings in Firefox, however, is unnecessarily painful, requiring you to alter the value of image.animation_mode to none or once under about:config. If you’ve never done this sort of thing in Firefox, more detailed instructions are available at mozillaZine.
• Opera: Altering your preferences for potentially flashing content in Opera is about as easy as it gets. Settings for animated GIF, Java, and JavaScript are easily available in the quick preferences. For Flash, FlashBlock for Opera 9 is available.
• Safari: Java and JavaScript are easily turned off under the Security tab in Preferences by unchecking Enable Java and Enable JavaScript. To eliminate Flash or Animated GIF, you can use SafariStand (OSX Only)
• OmniWeb [OSX Only]: Setting your preferences in Omniweb isn't as easy as in Opera, but it makes up for it with improved customization for your settings. Animated images can be set to animate fewer times or not at all In the Ad Blocking preferences tab, and Java and JavaScript can be controlled from the Security Preferences tab. Flash content can be controlled via the Blocked URLs button under Ad Blocking preferences. OmniWeb Help has detailed information on blocking flash content under the URL omniweb:/Help/reference/preferences/AdBlocking.html. One particularly nice feature of OmniWeb is that preferences can be set on a per-site basis, so you don’t have to turn off functionality for all of your web browsing just to accommodate jerks with technology at some sites. [Thanks to Mike Hostetler for pointing out how advanced OmniWeb’s treatment of preferences is]
• Internet Explorer: The No Flash! tool allows you to easily turn off Flash, Script, and GIF animations. Turning off Java in IE is somewhat more involved but Microsoft provides directions at their support site.

Earlier this week, I did an interview for the usability zone at DZone with Schalk Neethling. Schalk had several great questions about Design Accessible Web Sites, principles of web accessibility, not getting WET, and the future of web accessibility.

Over lunch yesterday, I joined Dr. Kathy King and Paige Eissinger to record episode twelve of their Transformation Education Live! podcast. Somehow I'd missed the “Live” part, which was a little scary for the first 5 minutes, but we ended up with a great discussion about Design Accessible Web Sites, tools for getting started with web accessibility, and some basic accessibility tools on the desktop.

So, it's no secret that I'm not a big fan of captchas—they're a major accessibility issue, they're a royal pain for users that don't have a disability that impacts their web usage, and they don't work very well at establishing security. Even so, I still hear a lot of comments about how we need captchas to protect our web sites. Tell that to Microsoft and Google.

The problem with captchas is that they have the same underlying weakness as strong DRM. Even if you don't consider the idea of teams of outsourcers being paid to enter captchas or clever sites that use a bait to get regular users to break a captcha for them, the simple fact is that a captcha is, by its nature, machine readable. Not only is it machine readable, but it also has to be (more or less) human readable. By remaining readable in this way, it is always going to be a matter of time before someone develops software that can circumvent the system.

Considering the amount of resources that go into upgrading captcha technology, and the relative ease with which they fall, perhaps it's time to stop building bigger mousetraps and devote our resources to attempting to build a better mousetrap.

I've been blown away by the reviews that the book has been giving. It's not that I'm entirely surprised—I mean I know it's a good book, but it's very humbling to hear that others feel the same way.

• SDTimes listed DAWS as one of ten titles “to expand one's view of IT”
• Cyber Aspect's Julie Smyth says “I'm happy to give this book a double thumbs up. It is well written, enjoyable to read and contains so much helpful information, it's hard to list it all here.”
• Ask Felgall's Stephen Chapman says “This Book provides both an ideal introduction to accessibility as well as a central reference to all of the different aspects of accessibility that you need to take into account when designing a web site.”
• Weblabor's Török Gábor gives DAWS a 9/10, but I can't tell you much more than that because I can't read Hungarian— If you can, and would be willing to translate, please let me know!
• Roger Johannsson at 456 Berea St gives DAWS a high recommendation, saying “There is not a lot of pedantery and preaching and ‘you must follow these guidelines exactly, or else’. Instead, the author focuses on the end result - if doing this or that actually makes the site more accessible. And in the end that is a lot more important than ticking boxes in a checklist.”
• NosillaCast #135 is a full half hour discussion between Allison Sheridan and Paige Eissinger about DAWS. I don't know where to start with this one—Paige and Allison's praise of the book was enough to make me turn pink for most of the afternoon!
• Paige also discusses the book briefly with Dr. Kathleen King in Transformation Ed Episode 11 I didn't know about this podcast until recently, but it syncs up with a few of my major interest areas and I want to listen in on the old episodes and keep up with the new ones.

Thanks to each one of you for your wonderful comments about DAWS!

A few weeks ago, I sat down and did a podcast over Skype with my editor, Susannah and Daniel Steinberg. I don't think Susannah and I did too badly for our first podcast and Daniel edited it together nicely. The podcast is available from the Pragmatic Bookshelf site and, if you can't or don't want to listen to the MP3, we also have a transcript of the podcast available (thanks to Kate for getting this out for me).

I've had a bunch of projects at work and in class that have kept me pretty busy the last few weeks, but in the meantime, the book has been slowly moving out into the world. Along the way, we've already gotten a few nice reviews:

• Techtalk Radio mentioned DAWS in their 11/25 podcast.
• Web Teacher gave the book a 4 of 5, saying they particularly like the ten principles for web accessibility.
• KnowProSE gives me a 9/10—“Jeremy Sydik did his time in the accessibility mines of the web and came up with a mother lode for the rest of us to enjoy.”
• CMS Wire says “The book intentionally avoids the nitty gritty details of W3C guidelines and rather lets the reader discover that making accessible sites need not be an ugly mandate, but rather a very humanistic approach to design. After all, no matter our ability, we all want a positive experience on the web.”
• James Pyles says at Tech Unity—“Sydik uses his writing style as well as his considerable experience in both computer science and cognitive psychology to present a unique perspective on this classic design issue and present it in an interesting and fun way. In an ideal sense, learning should be fun. Many times it's not, usually due to how the information is presented more than the information itself. This book teaches a topic all serious web designers should be well versed in and lets you enjoy the learning at the same time.”

Thanks to all of the reviewers!

Life is interesting sometimes. Not long ago, I was writing a tip in The Accessible Web about flicker and photosensitive epilepsy. I kind of went back and forth about whether this was a common enough issue to worry about. In the end, I decided that it was too important to not discuss in depth.

When video flickers at the right speed, some people have seizures. The degree of the seizure varies, but to be sure, this isn’t a pleasant way to relax watching television or a web video. If you test your video for flicker problems using Harding FPA or TRACE Center’s PEAT tool you can avoid inappropriate levels of flicker. If you don’t test it, you run the risk of seriously harming some of your users.

This was exactly what happened this week when a video introduction was rolled out for the 2012 London Olympics. A segment in this video featured a multicolor flicker that was not tested for problems and viewers suffered from seizures. Fortunately, it appears that fewer than a dozen people reported being affected by this video (An infamous episode of Pokemon a few years back had over 500 reported seizures). I’m not as concerned about the reported numbers as by the potential damage though—in the end, 23000 people in the UK were put at risk of seizures caused by this video.

Most of us don’t worry about things like the flicker rate of our content very often. It seems like a minor factor that effects only a few people. It’s never just a few people - a small percentage of the total population is still in the thousands. It’s also not a great way to do business. London mayor Ken Livingstone had these comments:

• If you employ someone to design a logo for you and they haven’t done a basic health check you have to ask what they do for their money.
• Who would go into a firm like that again and ask them to do that work. This is a pretty basic thing.

These are important things to think about. As web designers, we make our livings by serving an audience. If we allow harm to come to that audience, we allow harm to come to ourselves.

This is the other reason I haven’t posted much recently.

One of my biggest frustrations when I talk to other developers about accessibility is the inevitable question “What book should I look at?” I’ve never had a response that I’m completely comfortable giving, so I’ve been writing one. The Accessible Web: Creating Content for Everyone is a different type of accessibility book, written for real web developers with real projects.

In this book, we’re not going to spend all of our time looking at reams of guidelines that are written for accessibility experts instead of for developers. Instead, I’ll introduce some basic principles for accessible development and we’ll look at how you can put them into action. Because a lot of people out there talk in terms of the guidelines, we’ll look at them enough to be comfortable using them for testing and talking about them when they come up.

I’m also not going to tell you that you’re an evil person if you like pages that aren’t black and white with blue links. This page should be proof of that. I’m not about making the world worse for the non-disabled—I want the best possible results for all of our users and we’re going to look at how we can provide images, video, Flash and PDF in an accessible way that still looks good to our sighted users.

The book isn’t finished yet, and won’t be on the shelves until late fall of this year, but starting today, Pragmatic Bookshelf is making the current version of the book available as a beta book. This means that you can get the parts of the book that are already finished and we’ll send you updates as soon as they’re written and edited. This also gives me the opportunity to let you ask questions before we go into print and make sure that the book is everything you want to know about building accessible web pages—and you can tell me if I’ve made any mistakes ;)

And thanks to Kate for the fantastic cover design!

I just got back from Orlando and ATIA 2005. The conference was a good experience, and I had a chance to meet a lot of major people in accessibility that I’d heard of. Since it was in Orlando, I also decided to take Kate along and extend the trip a little so we could visit Disney. While we were there, we also managed to get a few decent photos that I’ll post later.