WCAG 2

Shawn Henry writes of WCAG 2,

Over the last few months, the Web Content Accessibility Guidelines (WCAG) Working Group has been going through a process to ensure that WCAG 2.0 can be implemented. Developers and dsigners from around the world gave WCAG 2.0 a “test drive” in their own Web content.

The result: Successful implementations in a wide range of sites including education, commerce, government, and a blog; in languages including Japanese, German, English, and French; and using a wide range of technologies including scripting, multimedia, Flash, and WAI-ARIA. You can get the nitty-gritty details from the Implementation Report.

It’s possible that WCAG 2 could be the new accessibility standard by Christmas. What does that mean for you? The answer: it depends. If your approach to accessibility has been one of guidelines and ticking against checkpoints, you’ll need some reworking your test plans as the priorities, checkpoints and surrounding structures have changed from WCAG 1. But if your site was developed with an eye to real accessibility for real people rather than as a compliance issue, you should find that there is little difference.

mobileOK Basic Tests

I’ve mentioned this largely so you don’t have the same worries with them that I did. Crudely speaking, they’re an automated test that a site will be OK on a very low-spec mobile mobile device called the “Default Delivery Context” (DDC) so there are certain rules in the validator such as a page cannot be larger than 20K. This caused me some degree of tizzy, until I read the caveats at the top of the specicaton:

mobileOK Basic primarily assesses basic usability, efficiency and interoperability. It does not address the important goal of assessing whether users of more advanced devices enjoy a richer user experience than is possible using the DDC.

…The Best Practices, and hence the tests, are not promoted as guidance for achieving the optimal user experience. The capabilities of many devices exceed those defined by the DDC. It will often be possible, and generally desirable, to provide an experience designed to take advantage of the extra capabilities.

So my advice: make your pages as long as the content requires, no longer or shorter. Use the images that the content and design needs, and let the user decide whether he or she wishes to accept your images. Make sure all images that convey information have explanatory alternative text for those who can’t consume your images.

Now that sounds familiar…

Participants will have access to lectures and assignments providing
hands-on practical experience with using W3C’s mobile Web
Best Practices. They will have direct access to W3C experts
on this topic who are the instructors for this course. Participants will also
be able to discuss and share experiences with their
peers who are faced with the challenges of mobile Web design.

For more information about the course, instructors, topics, and to view a free sample course, visit Online Training Course: An Introduction to W3C’s Mobile Web Best Practices

Thanks also go to Henny Swan for posting an entry about this on her site at Want to Get Your Content Mobile.

Update: Registration is full and now closed.

The URL you need to point your mobile device to is: http://dev.w3.org/2008/mobile-test/test.html.

That’s a bit of a fingerful so there’s also this short version: http://tinyurl.com/37e33p.

But if that’s too hard to remember, i maded u a url: http://icanhaz.com/wt (let’s say it stands for “web test” but really I chose those letters because it’s short and they’re the first letters on the 9 and 8 keys of a T9 keyboard).

Or if your phone can read QR codes, give your fingers a rest and point your phonecam at this image.

Once you’ve tested your device, you can send a picture of the results to [email protected] and it will be added to the screenshot gallery. If you have any feedback on the test itself, join in the discussion on the group list: [email protected]. Be sure to read the test documentation first though.

On your marks, get set, test!

There are two aspects to this release that make it particularly interesting:

1. Mobile Safari is now poised to explode in terms of market share, possibly driving a lot of innovation in the handheld browser market, and
2. developers now have a far less expensive means of obtaining and testing on the new browser.

What do you think of this announcement? What repercussions do you think we’ll see?

A few days ago, Scott Gilbertson declared “[t]he iPhone is Internet Explorer 4 all over again,” alluding to the walled-off nature of many web sites and apps being developed just for the iPhone (as they were back in the day with IE 4). Joe Hewitt was quick to reply, arguing that being like IE 4 is not such a bad thing, claiming that the devices drives innovation on the web, which is what’s needed.

So where does that leave us? Well, I’m not sure I’ve figured that out yet, but I wanted to put together some of my thoughts and see what you think as well.

The Good

The version of Safari packaged with the iPhone is, without a doubt, the best mobile browser I’ve seen to date. It renders normal web pages brilliantly and the pan and zoom functionality offers a pleasant alternative to the re-flow or squeeze-it-in display models of other mobile browsers.

The Bad

Two words: “standards support.” While mobile Safari performs brilliantly when it comes to CSS rendering, it does have a few problems.

1. It does not apply handheld stylesheets – I can understand the use of screen styles when handheld stylesheets aren’t available, but it would be easy to include a switch to turn off screen styles and load handheld styles if a handheld stylesheet is encountered.
2. Event handling – The iPhone introduces some new interaction models, but has not (according to the documentation or under user tests) given us a window into those actions (such as zoom, pan, etc.). Furthermore, as Joe points out, events like mouseover, mousemove, etc. are not supported. Sure, some of the traditional events have no meaning in the iPhone interface paradigm, but the virtual keyboard doesn’t even fire onkey* events and there’s no way to know if the user is scrolling.
3. iUI – I feel kinda bad placing iUI in the “bad” list, but the markup required to make it work leaves a lot to be desired. It is a great interface, but it enforces some pretty awful coding practices. I’m hopeful it will get a little more attention on the standards end and move into the “good” category.

The Ugly

Alright, so the big ugly to me comes down to one thing and one thing only: iPhone only apps/sites.

Since its release, designers and developers have been building interfaces to their sites and applications for the iPhone. Unfortunately, many have been doing so in a way that leaves the remainder of the mobile web with nothing. Personally, I’ve been kind of torn about mobile segmentation as I feel it goes against the “write once, deploy everywhere” ideal of web standards, but I understand the need for stripped-down interfaces on mobile devices (due to the currently high cost of mobile bandwidth in many places, etc.). But now we are witnessing a schism within the mobile world, dividing it into people with the iPhone and everyone else. This, I feel, is bad for the web and particularly bad for the mobile web.

For the record, I don’t buy the argument that web standards stifle creativity; in fact I believe quite the opposite: web standards enable creativity. It is my firm belief that we owe a great deal of the innovation on the web today to web standards (including XHR, which, as you recall is not a standard…yet). It was only when we had a solid foundation upon which to build that our creations could reach such lofty heights.

So what do we do?

While it is arguable that the iPhone is a lot more fun to design and build for than other mobile browsers (even the venerable Opera Mini), that does not mean it’s OK to hang a sign on the door of your web shop reading “No Blackberries.”

Now don’t get me wrong, I am not saying that you should not support (or even cater to) the iPhone. All I am saying is that you should not support the iPhone and snub all other mobile devices. If you want to build a mobile interface to your app, do it like Twitter and others have. Writing a POSH interface is dead easy and, even with the lack of solid CSS support on most devices, it is usable by pretty much anyone on the mobile web. So start there. Then use progressive enhancement to add new layers of interaction to your mobile site/app. It not only makes sense, but it’s The Right Thing To Do™.

As we expand our horizons from desktop to wireless, browser support isn’t going to get easier. In fact, anyone who has done wireless development already knows cross-device and wireless agent development is much more insane than anything we deal with on the desktop.

The battles we’ve fought and ultimately appear to be winning for screen-based browsers have done nothing to inspire those in the wireless manufacturing and user agent environment to think standards. Add to that literally thousands of unique wireless devices, many with proprietary user agent implementations, and if you haven’t gone bald, gray or lost bone mass, you’re about to.

Here’s a little taste, and I do mean a little, of what kind of XHTML support major agents sport.

“Okay,” you’re thinking. “That doesn’t look so bad! It’s pretty much either XHTML MP or XHTML Basic, right?”

Wrong. Despite the simplicity of both the XHTML MP and XHTML Basic specifications, there’s such inconsistent implementation between the individual devices and browsers it’s enough to make a standardista give up the old holy ghost.

Ready for another morsel? If you’ve read this far, you know you are. So here’s a little taste (and I do mean little) of mobile device and browser inconsistencies:

• title element woes. Some browsers render it as text, some use it properly within existing agent chrome, some use it for bookmarking. Which does what? You’ll have to test to find out, because even devices coming from the same manufacturer are likely to have different rendering capabilities
• Device manufacturers like to confuse us. Samsung, for example, uses the AU System browser but, get this, implements their own rendering engine. That’s almost as weird as Netscape 8.0 and its dual Trident / Gecko rendering engines
• Provider gateways are not our friend. If MIME types and content negotiation in XHTML 1.0 and 1.1 annoy you, try this on for size. Provider gateways can totally influence the rendering of your documents. Some are sophisticated: They let only valid, conforming XHTML through. Some don’t. Some might translate any graphics, or drop them all together

I did say this was only a little taste, right? Well, we haven’t even covered mobile CSS support, which is either very limited or downright non-existent in most mobile environments. Where it does exist, what happens to many of the best practices we teach for the screen? Out the window! Why? Because most existing mobile browsers that support CSS do not cache CSS! As a result, any CSS in use must be embedded or inline.

I’ll revisit CSS in mobile devices on another day. Right now I think I need to go color my hair.

This entry cross-posted to take your comments.

Jim included additional resources for introductory, practical, and advanced topics. One of my favorite articles is the March 2004 Webmonkey overview authored by Heidi Pollack, The End-All Guide to Small-Screen Web-Dev.

Also listed are links to Standards for Markup and CSS.

Tip o’ the chapeau to Jeffrey Zeldman.

This formal working relationship enables the two organizations to collaboratively engage in exchange of technical information and contributions. The result will benefit developers, product and service providers and others, by providing standardized technology at their disposal to accelerate the development and deployment of new mobile applications and services.

Is this good news, or is this good news?

(Hat tip: Kyle Barrow)

The OMTP group aims to define those platform requirements necessary for mobile devices to deliver openly available standardised application interfaces that will provide customers with a more consistent and improved user experience across different devices, whilst also enabling individual operators and manufacturers to customise and differentiate their offering.

OMTP doesn’t sound like something you should say in polite company, but it sure sounds good to me. My cell phone and I wish you all the best!