January 2010 Browser Stats

Mashable has posted information about browser usage (Browser Usage Stats: Chrome Grows While IE and Firefox Shrink) stats from Net Applications. In short, Chrome continues its climb at the expense of Explorer and Firefox. The original data comes from January of 2010 and shows that Chrome has gained 0.57% to get to 5.20% of browser share. Firefox dropped (-0.20% to 24.41%) as did Internet Explorer (-0.51% to 62.18%). Opera and Safari hardly moved.

It's no surprise Chrome has climbed. It's a good browser for those who are technically inclined and don't need all the bloated features of the other browsers. It's speed (especially with JavaScript) and memory management have made it my default browser on my Ubuntu netbook, even though it still has issues rendering Facebook's message inbox and photo gallery management tools. Even though Firefox 3.6 was just released, the average user won't see a huge benefit from switching browsers and probably won't bother as a result (although I do like the new type support).

Internet Explorer is the troubling one in the mix. IE8 is now up to 22.31% of the market, but IE6 still beats out IE7 (20.07% and 14.58%, respectively). That equates to 1 in 5 users is still surfing on IE6, known for its security holes and buggy rendering.

Many people (web sites, developers, forums, etc.) have been calling for the demise of IE6 in some way for quite a while now. Google has just joined the list (Modern browsers for modern applications, from the Google blog), announcing that they will phase our support for IE6 in Google Docs and Google Sites as of March 1. You can see other sites (far smaller, for the most part) who are trying to push IE6 out to pasture, just visit ie6nomore.com. Whether or not this will speed the end of IE6's reign is to be seen. Catch up on some anti-IE6 articles at Mashable using their IE6 Must Die tag.

I am curious, though — am I the only one who still uses Lynx?

Too Soon to Advocate HTML5?

At the site Rebuilding the Web there is plenty of content questioning the current process and chaos around HTML5 and related specs. A piece that drew my attention echoes the dust-ups I have had over HTML5 (and XHTML2) and whether it's a good idea to push it so hard when it isn't even an approved spec. Check out Is it irresponsible to advocate using HTML5 before it is ready? to see some interesting examples. If you are new to the developments in HTML5, read my post The Latest on HTML5 from last week.

Given how few people actually code HTML by hand, and given how so many web sites are powered by some sort of CMS, WYSIWYG editors have become a de facto truth for how most web page content is marked up (except this one, of course). As a result, HTML Tidy (originally a W3C project, the same standards body working on HTML5) has been incorporated into many editors to help remove and clean terrible, invalid markup.

The problem is HTML5 is so lax in its requirements, as compared to previous versions of HTML, that HTMLTidy can be more of a hindrance. For example, the HTML5 doctype is so truncated that HTMLTidy sees it as an error and sets it to HTML3.2. It is now legal to wrap block level elements in anchors, something that a WYSIWYG editor (like CKEditor or TinyMCE) would immediately try to re-nest, resulting in a potentially broken hyperlink and extra elements to satisfy the nesting.

With the examples in the article, I certainly cannot foist an HTML5 site on my clients. It would render their WYSIWYG editor potentially dangerous to their page content. And for those clients who can access and manage the templates used by the CMS, we run the risk of making their existing editors, or even HTML knowledge, useless.

It is far too soon to advocate HTML5 for client projects or real-world applications. We need a final spec that is free of infighting among its authors, we need browsers to support the core elements, and we need WYSIWYG editors that can understand this new syntax without the need to retrain our users.

Define "Cognitive Disability"

This image is borrowed from the WebAIM article on Cognitive Disabilities.

In the blog post Definitions of "Cognitive Disability" by John Rochford, we can see that it's not so easy to define the term "cognitive disability." Given how often this term appears in accessibility statements and requirements for web sites, the author was motivated to find a clear definition. His goal:

Find a recent, functional definition of "cognitive disability" written by an appropriate U.S. federal government agency, and adopted by government agencies and education institutions throughout the country.

This goal, of course, was not as simple to meet as his statement implied:

It appears no authoritative source has published a widely-used and accepted functional definition, nor a clinical one.

His post details his search process, with hyperlinked references, along with what he actually found. His closest match was a clinical definition from the U.S. Department of Health and Human Services, Administration for Children & Families.

This is problematic when the W3C WCAG 1.0 uses the term so freely, such as in Guideline 14: Ensure that documents are clear and simple:

Consistent page layout, recognizable graphics, and easy to understand language benefit all users. In particular, they help people with cognitive disabilities or who have difficulty reading.

Who makes the final decision on whether a document is clear and simple to a user with cognitive disabilities? How will a web developer satisfy this when required to meet these guidelines by law or contractual obligation? How will a web developer protect him/herself if sued as a result?

The Requirements for WCAG 2.0 has a section titled Clearly identify who benefits from accessible content and lists users with cognitive disabilities, but provides no further information.

Without definitions or pointers to definitions of what the term "cognitive disability" means, web developers are faced with more than a moving target. This is an unknown target when it comes to working to ensure that a web site meets WCAG (version 1 or 2) guidelines.

You can find a very open-ended definition of cognitive disabilities at the WebAIM site. While this may help you as a web developer who needs to support disabled users, this doesn't necessarily mean you will comply with a definition from W3C or the federal government, perhaps because there is none.

Related post: Developer Discusses Dyslexia and Dyscalculia.

Mashable on the Web of Tomorrow

Mashable bills itself as a social media guide, although it tends to cover Web 2.0 (yes, I am still not a fan of that term), current trends (viral hits and the like), and even a fair amount of randomness. Ben Parr, Mashable' co-editor, just wrote the article What the Web of Tomorrow Will Look Like: 4 Big Trends to Watch where he outlines his own idea of where the web is going. Similar to how Google's CEO described the web in 5 years (Google CEO Describes Web in 5 Years), where the conversation was framed in the context of Google's experience and core focus, Mashable's perspective is also coming from its own place in the social web and as new media pundit. The quick breakdown:

1. The Web Will Be Accessible Anywhere

Given the increase in Wi-Fi access (from your laundromat, from a neighbor, and so on) and 3G and 4G networks, it's just a matter of time before Americans (and those in other countries) decided that wireless broadband access is a right. It's just a matter of time before it's not just an oddity but an inconvenience to be somewhere without internet access.

2. Web Access Will Not Focus Around the Computer

If you saw my post on Friday about mobile internet access (Mobile Internet Use Continues Climb) then you know the numbers support this. People are increasingly moving to wireless mobile devices for day-to-day access and to use custom applications (on-demand media downloads, GIS and mapping, augmented reality, and so on). This doesn't mean the web is moving to the refrigerator (I still don't understand a web surfing fridge), but that users are no longer tethered to a computer to complete mundane tasks online. With new devices, like MP3 players and book readers, you wouldn't generally use your computer to update them anyway.

3. The Web Will Be Media-Centric

While here Parr talks more about the interface than the content, it leads to the conclusion that people are going to be downloading movies, songs, books, articles, etc. We've already seen that trend increasing as media devices (again with the MP3 players and electronic book readers) become internet-enabled and as consumers push for media readers/players in the mobile phones and other platforms.

4. Social Media Will Be Its Largest Component

Humans are social creatures. Facebook, Twitter, and others have grown at s breakneck pace. More and more web sites include comment areas. Some people only get online to check on their friends through social media sites. Social media will certainly continue to be a driving force behind much of the casual use of the web in general.

Mobile Internet Use Continues Climb

Last week Nokia chief executive Olli-Pekka Kallasvuo stated that mobile devices provide the majority of phone subscribers with internet access, often their first and only internet access (reported in the article Nokia: Majority of world accesses internet through a mobile). He feels that as more and more people sign up for internet access on their mobile devices it may be eroding the base of computer-based internet use.

Supporting Data

Back in 2008 Pew Internet predicted that by 2020 the mobile device would be the primary tool worldwide for connecting to the internet. I recommend reading some of the comments made by survey participants in the 2008 Pew Internet & American Life/Elon University Predictions Survey. I'm tempted to reproduce them all here, but that would be plagiarism and make for a far lengthier post.

In April 2009, Pew Internet (Pew Research Center's Internet & American Life Project) ran another survey and reported that 32% of Americans have used a mobile phone to access the internet for email, instant-messaging, or information hunting. On a typical day, 19% of Americans use the internet on a mobile device. This represents a 73% growth from their survey 16 months prior.

The same report also found that African Americans are the most active mobile internet users, with 48% of them using mobile devices to access the internet and 29% accessing the mobile internet on a typical day. In addition, over the 16 month run between surveys, African Americans nearly doubled the average American growth rate by increasing 141%. You can see that data in the press release.

In December 2009 (last month), the number of mobile internet users hit 450 million, with a prediction that it would hit 1 billion by 2013 (as reported by IDC). Nielsen reported (as retold in this blog post) that mobile internet access by US users climbed most among teens and seniors back in July. While the mobile web in the US is still about 53% male, new female users have climbed up in the ranks nearly twice as fast as new male users.

"Digital Divide?"

The notion of a digital divide for African Americans has some resonance when thinking about the wireline internet, said John B. Horrigan, Associate Director of the Pew Internet Project and principal author of the report. But when you introduce the mobile internet, the picture changes and African Americans are the pace setters.

Often in the U.S. minorities fall into the lower socio-economic classes. In general this seems to coincide with my own experiences (client, community, and otherwise) that suggest that given the often cheaper hardware cost for internet-enabled mobile devices, this is a far more economic and portable way to get on the internet and stay connected. Online services that target specific communities need to keep in mind how their users access the web in general and must be prepared to support it.

Mobile vs. "Real" Internet

I have had many experiences where users feel that the internet they use via their mobile devices is somehow lesser in quality, value or feature-set than the internet they access via their computers. This perception is driven primarily by the capability of the mobile device and how sites are configured.

For example, surfing on an old Blackberry via WAP would have been a much less engaging experience, but the advent of the iPhone and mobile Safari is an example of how mobile browsers are now capable of accessing the same content as a traditional desktop browser. Lack of Flash, PDF or video support has been largely cast aside as mobile devices can now play video and have embedded PDF viewers. The Flash roadblock is also sliding away depending on the device you use. No longer must a site developer create both a WAP and HTTP/HTML site, but can now create a traditional site with some additional hooks for mobile devices.

Some of us even prefer the mobile versions of sites to their traditional counterparts. For example, I typically use Facebook through my Windows Mobile device, moreso than via my desktop browser. In my case, I prefer the timeline and ease of access compared to the script-laden madness of the regular site.

Back in November the blog Communities Dominate Brands posted a diatribe on this very topic, Why Mobile Data Services (or 'Mobile Internet") is 'better' than old legacy PC based internet.

Firefox 3.6 Is Here

As you may have noticed in my warning tweet yesterday, Firefox 3.6 is out.

Firefox 3.6 was released today and is the very browser I am using to write this post. So far it hasn't blown up, and I abuse my browsers with tab counts around 70 or so. It's memory footprint isn't any smaller, but I am not terribly surprised by that. I am disappointed to find out that my HTML validator plug-in is not compatible, but it should be updated within a few days if prior experience is any guide. I would recommend against using the personas feature, the skins they put on your browser just make it harder to use when you have your toolbars full of buttons. You can grab your own copy from the Firefox 3.6 download page.

The Mozilla blog announced it today along with the following features and updates (copied from their post):

• New CSS3 features: Improve your style with support for gradients, multiple backgrounds, pointer-events and more.
• Drag and Drop: It has never been easier to move files from your desktop to the Web.  You can now drag content into the browser window and leverage the FileAPI for instant access to that content.
• File API: Support for the latest HTML5 specification allows Web applications to access local files and interact with them in new ways.
• Web Open Font Format (WOFF): Add a touch of typography to the Web with WOFF support, which makes even more possible than the existing support for OpenType and TrueType fonts.
• Device orientation: Discover new ways to manipulate and interact with Web content with access to the orientation of supported laptops and devices.
• XMLHttpRequest improvements and more…

Back in October I posted about coming support for Web Open Font Format (WOFF) in the post Firefox 3.6 to Support Web Open Font Format. In case it's not obvious by now, that is the feature I will be trying out the most in the next few days.

Accessible Video and Transcripts

With HTML5 on the horizon, it is becoming far easier to embed video on a web page than it has been. Sure, you can drop some code copied from YouTube, but you have little control over the HTML or the video output. Once you do have your video, you also need to bear in mind that not only are video (and audio) transcripts good practice, they are required by law for many organizations.

HTML5 Video Captions

Bruce Lawson has been kind enough to put together an example and code (Accessible HTML5 Video with JavaScripted captions) for his method to embed synchronized captions, using JavaScript for the synchronization, with a video embedded using the HTML5 video element. The caveat here is that you need to have a browser that supports the open Ogg Theora codec. You can check out the sample video if you have such a capable and sweet browser.

YouTube Automatic Captions

Some of you may remember my post about how YouTube can now automatically caption your videos using speech recognition software. While the results can be interesting, you can at least edit the captions coming out of YouTube. Terrill Thompson describes how he grabbed the .sbv caption file from his video and updated it, then uploaded it back to YouTube for a much more useful result.

Why Transcripts?

Shawn Henry leads the education and outreach effort promoting web accessibility at the W3C Web Accessibility Initiative (WAI). She recently wrote an article titled Transcripts on the Web: Getting people to your podcasts and videos that explains why you would want to do this, some best practices, and even some resources. For example, in addition to supporting users who are deaf or hard of hearing, she points out that search engines can index a transcript where they cannot index a video or audio file. This adds to the overall SEO strategy for any site. Her best practices go beyond what the captions mentioned above provide: she points out that sometimes we need to state how many people in a video raised their hands in response to a question. She is good to not browbeat the reader with a reminder that WCAG 1.0, WCAG 2.0 and Section 508 all require transcripts — at least not until the end of the article.

If you have a few minutes after reading all these other links, consider reading the interview with Shawn Henry, W3C's Shawn Henry on Website Accessibility, from last week over at Freelance Review.