Blind Students Sue Over Online Law School Applications

The Chronicle of Higher Education reported that three law students and the National Federation of the Blind (NFB) are suing four law schools in California claiming that the online application system is not accessible to students who are blind (Blind Students Sue Law Schools Over Online Applications). Specifically, the online application lives at the web site of the Law School Admission Council. The four colleges drive applicants to this web site to complete online applications. The first version of this suit started in February 2009 with the NFB and one student suing the admission council, but was just modified to add more plaintiffs and defendants. NFB issued a press release on Wednesday outlining its position.

The outcome of this case may be closely watched, since there is a lack of case law that defines how ADA and Section 508 compliance can and should be implemented. Given the regular debate between web developers and accessibility advocates about the nuances of the meaning and application of assorted web technologies to achieve maximum accessibility within a web site.

Back in 2008, many of us watched the lawsuit between Target and NFB for just such an example of case law. Instead, they settled the lawsuit and NFB walked away at least $200,000 richer. As it is, Target was really only accountable for making the site more accessible to the blind, not all users. The WebAIM Blog (Target lawsuit settled) outlines some of the reasons that lawsuit didn't do much to advance accessibility compliance or understanding, certainly not past providing for the blind.

Prior cases that started off as high profile (in the world of accessibility) such as the Sydney Organising Committee for the Olympic Games' (SOCOG) 2000 Olympic web site and America Online (its software more than its web site) were also settled without clear direction for accessibility practitioners. In both of these cases, the complaints were also filed by blind users and changes were made that in retrospect are almost laughably easy (they were then, too) such as adding alt attributes to image tags.

Given the prior history that these cases settle, and given that NFB might be more motivated (based on the pay-outs from the Target case) to settle than to use this as case law for the rest of the web, I don't expect to see anything terribly useful coming from this case. Even if it did, it will still likely only address accessibility for the blind, leaving other disabilities out of any potentially useful case law.

Read More

Google Caffeine Is Live

Late yesterday Google announced the launch of its new web indexing system, Caffeine. According to Google, it provides 50% "fresher" results and is the largest collection of web content it has ever offered.

The big push for this new indexing technology is the rise (explosion, really) of real-time data on the web. With Twitter acting as a de facto news source for so many, and with other services such as location-based social media, rapid-fire blogs, mailing list archives and the like pushing data live at an ever-increasing rate, Google's old model of updating once a week (or every two weeks) just wasn't cutting it. We've seen Twitter integrated into Google search results already, but that has been strapped on to results that were otherwise out of date.

Google provided the image you see at the top of this post as an example of how the old index worked compared to how Caffeine works. Unless you speak blocks and the Bohr model, it really doesn't say much (except that I worry about the little guy in the cloud taking a camera to the head). The gist is, the old index was built in layers, with some content being refreshed more regularly than other content. Sites like CNN might live at the top of the index, being refreshed regularly. Sites like my personal pages might live at the very bottom, only being refreshed when someone goes in with a shovel to scrape the cruft off the edges of the database.

With Caffeine, they've flipped all that over. The crawler is always out, always indexing, and it's always updating the index. Whether it makes it to your site today or tomorrow is unknown, but now at least it's more likely to be picked up sooner rather than far far later. This is how Google describes it:

Caffeine lets us index web pages on an enormous scale. In fact, every second Caffeine processes hundreds of thousands of pages in parallel. If this were a pile of paper it would grow three miles taller every second. Caffeine takes up nearly 100 million gigabytes of storage in one database and adds new information at a rate of hundreds of thousands of gigabytes per day. You would need 625,000 of the largest iPods to store that much information; if these were stacked end-to-end they would go for more than 40 miles.

As a searcher, you may find that you are getting more timely results more regularly. The effect may not be immediate, however. I have already been trying it out, but my tweets aren't really a good example.

Read More

TED Talk: The Future of UI

John Underkoffler is the science adviser who was behind the user interface ideas used in the movie Minority Report. In his TED talk, he shows examples of interfaces made up of real-world objects, providing interaction far different than what we know today. Given the success of the Wii, multi-touch interfaces, and the coming controller-free Project Natal for the Xbox, this shouldn't seem too far-fetched. How these ideas will be polished and ultimately deployed will depend on many factors, including what hardware manufacturers are willing to support. This is a talk about ideals, so don't expect to see much of a nod to accessibility for people with mobility impairments, although that will certainly be one of the issues to be addressed before this can see general use.

Read More

Luke Wroblewski on Mobile First

Dan Benjamin and Jeffrey Zeldman interview Luke Wroblewski about the evolving nature of the web as mobile devices start to dominate the stats of some sites (5 by 5: Episode 6: Mobile First, 51:37). They bounce around discussing issues from design to technology while Luke peppers the conversation with statistics about mobile use. Overall, the pitch is that designing for mobile platforms first helps circumvent some of the issues of having to rebuild a design to work for mobile (see his original article, Mobile First).

The next day Luke wrote up an article where he takes some of his points from the interview and expands on them (Mobile First Helps with Big Issues). One of the points from the interview that he expands on is the idea of how a limited screen size forces a developer to prune to the most necessary bits (navigation, functions, etc.).

When you are working with a 320x480 pixel screen (iPhone, Palm Pre, first generation Android phones), 80% of the screen space you had at 1024x768 is gone. [...] Losing 80% of your screen space forces you to focus. You need to make sure that what stays on the screen is the most important set of features for your customers and your business.

Another point he expands on is the idea of making web sites appear and function the same in every browser. Web developers have struggled with that for years and it's an expensive proposition for many organizations to support. He (and Zeldman bolsters it in the interview) argues that consumers are starting to realize that web sites can look different in different browsers, and in many cases should look different. This logic expands (in the interview) to address browsers like Internet Explorer 6 and other legacy platforms.

The onset of many networked consumer devices with different capabilities and limitations has begun to open a lot of people's eyes to the fact that Web sites don't have to look and act the same in every browser. In fact, they shouldn't. Designing for mobile first establishes that up front.

In the interview, Luke points out that in 2009 over a million touchscreen devices were sold per day. He has a new post today with updated statistics on the mobile market (Data Monday: Mobile Market Update). Some of the other data points:

• Worldwide mobile phone sales to end users totaled 314.7 million units in the first quarter of 2010, a 17 per cent increase from the same period in 2009, according to Gartner, Inc. Smarpthone sales to end users reached 54.3 million units, an increase of 48.7 per cent from the first quarter of 2009. (source)
• Growth in the mobile devices market was driven by double-digit growth of smartphone sales in mature markets. Smartphones accounted for 17.3 per cent of all mobile handset sales in the first quarter of 2010, up from 13.6 per cent in the same period in 2009. (source)
• As of Q1 2010, Nielsen data shows that 23% of mobile consumers now have a smartphone, up from just 16% in Q2 2009. Nationally, the iPhone's still in second place, with a 28% market share compared to RIM's 35% (Android has 9%; Windows Mobile has 19%). (source)
• 14% of mobile subscribers have downloaded an app in the last 30 days. (source)
• Facebook, Google Maps and Weather Channel are the most popular apps across smartphones. iPhones: Facebook (58%), iTunes (48%), Google Maps (47%) Android: Google Maps (67%), Facebook (50%), Weather Channel (38%) Blackberry: Facebook (51%), Google Maps (34%), Weather Channel (28%) (source)
• Nearly 5 million consumers downloaded the new Skype iPhone app in four days. (source)
• eBay's iPhone app has been downloaded 10 million times, and the company expects $1.5 billion to $2 billion in transactions to be conducted using the mobile application this year. The eBay iPhone app was responsible for $600 million in volume last year. (source)

Read More

The Future of Check-ins (at evolt.org)

Last week Mashable featured a post asking if location-based services are all just hype. Continuing the geolocation theme Mashable has a new post, What the Future Holds for the Checkin, by a guest blogger/columnist. I have a reservations about how well this article delves into future opportunities, so I just toss a few out here.

Please header over to evolt.org to read my article, The Future of Check-ins. It will only be there for eternity, or until the world ends, so make sure you head over there soon. To make sure you see this link, I am repeating it:

Read The Future of Check-ins at evolt.org

Read More

SVG Progress Bar Contest

Thanks to the W3C Twitter feed, I discovered a W3C blog post about an SVG contest, "No Bit, Sherlock." While the W3C may be pushing the contest, they aren't the sponsors. The contest is produced by Web Directions, an organization founded by John Allsop and Maxine Sherrin to create web developer conferences around the world. They pushed Microsoft UK to pony up some prizes for a contest, owing to Internet Explorer 9's plans to support SVG, something sorely lacking in all prior versions of IE (you can grab an Internet Explorer 9 preview release if you really want SVG now).

The gist of the contest is simple: Create a progress bar in SVG. Contestants are allowed leeway in how it looks and functions, but it must adhere to two key elements:

1. It must indicate to a user when waiting in an indeterminate state, and
2. it must indicate to a user how much a process has progressed.

Here's the catch: It must be submitted by June 11 at 2pm, British Summer Time (yeah, I'd have to call someone in Britain, too). The date was probably chosen to coincide with the Web Directions @media conference in London, June 9-11. You can read John Allsop's blog post about the contest and why they thought it up.

The criteria, from the "No Bit, Sherlock" site:

1. Your control has to work acceptably in the latest versions of Opera, Safari, Chrome, Firefox, and Intenet Explorer 9, so it would probably make sense to at least give it a look see in all these browsers.
2. Your SVG has to validate.
3. The judges will also pay attention to accessibility factors - hint - investigate the ARIA role attribute.
4. And, they'll take a quick peak under the covers at your code, so the cleaner and more legible that is, the better
5. They'll also consider how well the control communicates the two states described above, how attractive it is, and if it has that x-factor, then all the better.

Further details, including the list of judges, prizes, and even some SVG resources are all at the contest site. If you are new to SVG, I suggest you take a look at the SVG information at the W3C site.

Read More

Smokescreen Brings Flash to iPad, iPhone

Smokescreen - iPad demo #1 from Chris @ RevShockAds on Vimeo.

Now that it's clear that Apple has no intention of letting Adobe Flash run on the iPad or iPhone, workarounds for Flash are even more compelling to developers. Smokescreen, primarily by Chris Smoak, bypasses the need for the Flash plug-in by pulling in the SWF binaries and decompressing them in JavaScript, yanking out the images and audio and putting it all back together with the vector data rendered as animated SVG. Simon Willison got the details and posted the technical process on his blog:

It runs entirely in the browser, reads in SWF binaries, unzips them (in native JS), extracts images and embedded audio and turns them in to base64 encoded data:uris, then stitches the vector graphics back together as animated SVG. Open up the Chrome Web Inspector while the demo is running and you can see the SVG changing in real time. Smokescreen even implements its own ActionScript bytecode interpreter.

You can see demos of Smokescreen running StrongBad emails and ad banners at the site. If you are running Internet Explorer (any version), then these demos won't work for you. In general, you'll need the most recent versions of Firefox, Safari, Chrome or Opera to see the demos. A couple of them run on the iPad or iPhone and there is even a video of it in action for those who don't have either device (see above).

The Flash movies don't run quite as quickly using Smokescreen as they would in the native Flash player, but that's to be expected when all the work is offloaded to the browser's JavaScript engine (8,000 lines of code weighing in at 175kb). I also noticed that sometimes text embedded in the SWF file either didn't appear at all or had some odd anti-aliasing. Given how new this is, however, I suspect these are surmountable obstacles. Given that Chris plans to release the code as open source, more developers will likely be able to contribute to pare this down.

What would make this even more interesting is if Adobe lent its support in some way. Since this has the potential to reverse the trepidation Flash developers now feel thanks to the increase in iPads and iPhones on the web, it may stave off any doomsday scenarios for Flash. It may also blow up Apple's plans to ultimately push Flash out of the market altogether unless they want to stop supporting the JavaScript and HTML5 that this utility uses to render the former-Flash movies. It's still too early to tell which way either company will go with this, if they do anything at all, but I suspect it will be interesting to watch.

Related Links

• Smokescreen makes Flash content visible on iPhone and iPad (video) at engadget.
• Smokescreen Converts Flash to JavaScript On the Fly at Gizmodo.
• Smokescreen Project Promises 'Flash Without the Plug-in' at Webmonkey.

Read More