South By Southwest Interactive - Day 2

Creating Findable Rich Media Content

The main things I got from this panel was that if you use your tools properly, and include content that people actually want and is useful, you will be found. Doing things like implementing RSS feeds will get your information out there, but it's of no use if nobody can make sense of it. The data and the content needs to be formatted properly, using all of the elements as they should be used. For example, don't just put your company's name in the RSS description - actually describe the feed.

The panel also briefly touched upon accessibility and Flash. It turns out there is an "accessibility panel" which lets you embed content into Flash objects which is then picked up by screen readers. Who knew?

The next panel, Accessible Rich Media, sounded similar, but was a bit more in-depth and interesting.

Accessible Rich Media

In my opinion, this panel went above and beyond explaining some of the issues dealt with in the accessibility world. There is much more to accessibility than screen readers - there are video-to-mp3 encoders, generic text-to-speech readers, security/OS/program-specific alerts, color-blindness/high-contrast computer settings, etc. The panel discussed many things I've never even thought of before, like how do visually impaired users "watch" movies online? And how do they interact with JavaScript widgets and Ajax? I used to just kind of assume that progressive enhancement would allow them to use these things without the "bells and whistles", but just because somebody is using a screen reader does not necessarily mean that they have JavaScript turned off - they're still going to get all of the user interaction, but they can't see it and if you don't code it properly, they'll be totally unaware of the changes. You need to notify the screen reader of the updates being made.

I feel like lots of people like myself know about screen readers and know the basics of accessibility, but it's very difficult to fully grasp everything when you're not forced to (threat of litigation may change this in the US, but sites in other countries must pass W3C standards.) You can't really accurately reproduce the experience of someone using a screen-reader by imagining using one - you need to physically use one. And even then, without blindfolding yourself and going to a totally brand new site, you cannot traverse the site without a bias. The only real way to test the accessibility of a site's design is to have a disabled user test it. You can't fully rely on automated tests, because sometimes they will return false negatives, like telling you your <img> alt attributes are good, when they may have irrelevant text in them. Automated tests can't determine if that copy is actually useful. Automated tests also won't tell you that having an audio or video clip play automatically on page load makes it impossible to navigate a page or hear any content, god forbid there is no way for a blind user to find the controls to stop that clip.

Before attending this panel, I thought I had known a good deal about accessibility. I think the most commonly known "accessibility consideration" (aside from the usual alt tags, etc.) is that the navigation should actually be at the bottom of the HTML markup with a "skip to nav" link at the top. And that makes sense, but I never really applied it to anything else besides the navigation. Any sort of repetitive or gratuitous use of links or other text or controls can frustrate a disabled user, resulting in page abandonment and brand avoidance. I had heard this before about navigation issues, but it never really sunk in. Now I'm starting to realize that the whole page and structure needs to be taken into consideration - not just pieces of the experience. I have a lot to learn.

One of the things that really caught me off guard was that Becky Gibson, convinced the dojo toolkit team to make accessible widgets, and to do so, they needed to use <img> tags in places where almost any standardista would automatically implement CSS sprites. The reason for this is that background images are turned off when a computer is in high contrast mode - so any textual background images (image replacement) would then be lost. She mentioned that yes, this is bad for performance, but it's a must for accessibility (and after thinking about it, you could probably do sprites with <img> tags anyways.) I asked how using <img> tags compares to CSS image replacement with regards to SEO, but it didn't seem like anybody had a definitive answer yet.

This kind of reinforces my feeling that SEO (and definitely SEM) should not be a driver of website coding, rather it should be a result of doing the right thing. Yes, money comes in when people find a site, but what if only 80% of the people who come in have the physical capability of using that site? 1 in 3 households have a disabled member. 20% of the workforce has a disability. Accessibility issues need to be resolved. 1 in 12 men suffer from some form of color-blindness, yet I think this was the first time I'd ever seen anybody mention high-contrast mode. I'm guilty of this too - I've really never thought about it before. In general, there's a long way to go to widely implement accessibility best practices.

Towards the end of the discussion, the panelists also began talking about ARIA, but I went to a "Core Conversation" about that on Sunday, which I'll write about in the next blog post.

The rest of the day...

After lunch, I went to Video Production for the Web & Mobile Devices which basically consisted of people plugging their sites and work history with little to no useful information - technical or otherwise. The same thing goes for Social Network Coups - people just talking about stuff everybody already knew about. I had to leave that one early...