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.

Read More

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.

Read More

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.

Read More

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.

Read More

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.

Read More

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.

Read More

Against Vertical Navigation

There is a well written post over at Smashing Magazine by Louis Lazaris titled The Case Against Vertical Navigation. I have made this argument to my own clients (and other web professionals) many times, often with feedback that implies the client knows how users actually surf. This article wraps up the same points I've made and provides some pretty screen captures. The core points follow...

It Discourages Information Architecture

Using a content management system is the best way to demonstrate how true this is. Sites are no longer made up of a few top pages and perhaps one level of sub-pages. A well-structured press section (with archives and categories) will blow up a left-side navigation structure pretty quickly. It also encourages site authors to keep adding top-level pages until the navigation bar is too long to be useful.

It Wastes Prime Screen Real Estate

So much of the valuable page real estate is taken with vertical navigation that the site will miss out on key promotions or cross-links, partly because authors get more cavalier about the length of words when they are stacked in a column. On longer pages, often the entire column is wasted with dead space below the navigation.

It Doesn't Conform to Real-Life Reading

Vertical navigation results in shorter line-lengths for content, especially if you add images, pull-quotes, cross-sells, blogrolls, and so on to the other side of the page.

Fly-Outs Aren't as Usable as Drop-Downs

Many clients opt for fly-out menus to alleviate the issue with multi-tiered sites, but users don't navigate them as well as fly-outs from a horizontal menu (what the article calls drop-downs). Not only is it physically more of a challenge with a narrower active area, but adding another level gets even more complex for users.

It's Not as Successful, According to Studies

Our own user group studies have shown this, and the article references some research and shows some heat maps that indicate where users look on a page.

The Few Benefits Are Negligible

Having very long names as the primary navigation links can seem like a benefit, but in reality users don't read the entire text, they just parse it for the nouns or action words. The ability to have as many links as you want is also a detriment as users eventually can't keep track of all the options.

Exceptions to the Rule

The author does provide some examples where this rule can be broken. There are some screen shots worth checking out that support the exceptions.

Read More

The Latest on HTML5

Many of us have been following the ongoing progress of HTML5 for some time now, alternately curious and confused by the nascent specification. Comics like the one above (from the CSSquirrel site) demonstrate the frustration many web professionals are feeling with the mixed messages they think they see from the W3C and Ian "Hixie" Hickson (HTML5 editor through the WHATWG) through recent updates and announcements.

Kyle Weems opens his blog post (Comic Update: The HTML5 Show (AKA, A Mess)) last week with the statement, "HTML5 is a mess." He argues that Hickson is working to get developers to adopt the WHATWG HTML5 spec over the W3C spec. He also cites examples where he feels Hickson is pushing developers to stop using HTML5 features, and further suggests that Hickson is trying to wrangle the future of all HTML as his own while he hands off an HTML5 version to the W3C while further developing HTML.

Peter Paul Koch (ppk) takes a different approach in his blog post (HTML5 means whatever you want it to mean). Peter references an IRC discussion where Jeremy Keith pointed out that there is no HTML5 spec which he can use for evangelism. Peter argues that HTML5 is vaguely defined almost on purpose, owing to the fact that technologies get pulled into web specs as they are adopted. He suggests that HTML5 is a continuation of Web 2.0, itself a continuation of DHTML. It's similar to the way that Netscape Communications Corp. got table into the HTML3 spec — it introduced them as something its browser supported, and developers jumped on it.

Andy Clarke (Malarkey) looked at it a different way in his blog post (Keep calm and carry on (with HTML5)). He argues, from his own experience, that W3C Working Groups are made of paid members who have an agenda to push their products and needs. He believes that those of us who are actually building web sites should ignore the chaos and just get on with using HTML5, CSS3, or other tools that get the job done. He reminds readers that the specs have changed over the years, as well as the support for those specs. No new HTML5 spec will change the way web developers go about doing their work.

Jeremy Keith (from Adactio) also blogs about this topic (HTML5 business as usual). He points out that the WHATWG is moving ahead on what they now call WHATWG HTML, which contains all of HTML5 as it was forked to the W3C, plus new and upcoming development. Keith then clearly splits the two up for readers to understand that the two specs are divergent — W3C HTML5 is on its way to becoming a candidate recommendation, and WHATWG HTML is the ongoing evolution of HTML beyond version 5. The rest of his post offers some insight into how and why there appears to be so much infighting and why the process is so confusing to those unfamiliar with it.

What Does This Mean for You?

Not a whole lot. In general, if you're a web developer who is just listening, trying HTML5 on projects, or actively evangelizing it, there's really no reason for you to change. The last real shake-up in this world came when XHTML2 was called off and all the XHTML evangelists felt like they were left holding the bag. That's unlikely in this case since there is no other equivalent spec for use in the web browser (not in the same way). All of those dust-ups we've seen are a function of a more public process as the specs are hammered out, something that wasn't much of an issue when the HTML4 spec was being drafted.

What we can expect to see is a new divide in whether people choose to support the W3C HTML5 spec, or the ongoing WHATWG HTML spec. Until browsers start supporting things in HTML5 (which is still not an official spec), then those battle lines may not be drawn for some time. At least not among web developers.

Resources

• W3C HTML5 draft specification (vocabulary and associated APIs for HTML and XHTML): http://dev.w3.org/html5/spec/
• WHATWG HTML5 (including next generation additions still in development) specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/

UPDATE Jan-21-2010: YouTube has rolled out a video player in HTML5 that doesn't use Flash. You need Chrome or Safari (or Chrome Frame for IE) to see how it works, and you may note that some of the features don't behave quite the same, but it's worth trying out. Go to the page to denote your preference for the HTML5 demo player and then surf YouTube as normal.

Read More

W3C: Contacting Organizations about Inaccessible Websites

For those of us who make a living working with organizations to help make their web sites accessible to users with disabilities, we've got it easy — the client wants to hear our recommendations. As users, however, all too often we stumble across an accessibility issue and don't know what to do to correct it. Granted, in my case I have a long history of making phone calls until I get somebody on the line, but I can speak the necessary lingo, not everyone else can.

The W3C WAI has just published a document that helps walk users through the steps necessary to contact someone about the issues you find, along with tips and sample emails. They call this document (simply enough) Contacting Organizations about Inaccessible Websites. Those familiar with the W3C should not be surprised that the title bears the [Draft] declaration at the front. The overview from the document (emphasis theirs):

Steps to help you report websites with accessibility problems are described on this page:

1. Identify key contacts
2. Describe the problem
3. Follow-up as needed

Additional tips include:

• Consider what approach will get the results you want
• Keep records of all communications for possible follow-up
• Encourage others to also provide feedback to the organization
• Use the sample emails provided below

Because the document is a public draft, the W3C is accepting feedback up to February 3, 2010. The WAI Interest Group (IG) has a mailing list for public discussion of topics, including this one. There is a little more detail about this process at the blog post announcing this document.

If you've ever been to site and clicked on the words next to a radio button or checkbox and had nothing happen (the button doesn't select), then this document is for you. In this example, the site developer has failed to use the label element. This one is the single biggest issue I consistently encounter (as someone who doesn't use assistive technologies as part of his daily life). So help out by offering feedback on the draft and/or notifying sites of issues.

Read More

Article: Lots of Twitter Followers Guarantees... Nothing

I've posted an article over at evolt.org and on my site titled Lots of Twitter Followers Guarantees... Nothing.

I discuss how Anil Dash posted a story called Life on the List where he describes his experience appearing on the Twitter Suggested User List. After watching is follower count shoot skyward, he was left feeling like there was no dialogue between him and these new followers.

The problem here is that employers, sponsors, partners, etc. expect to see high numbers of followers in a social media marketing campaign. Using some examples from Anil's article and framing the context I make my argument that a high follower count isn't necessarily a good thing, and certainly not the only goal.

Read More

ALL-CAPS: Harder to Read?

Susan Weinschenk, Ph.D. wanted to write an article about why it's harder to read text set in all-caps than text set as mixed case. The argument for this has centered around how people read words — recognizing a word shape from its letters, whereas an all-caps word has no unique shape. She started to research this idea for her article but could find little to support it. Her article, 100 Things You Should Know About People: #19 — It's a Myth That All Capital Letters Are Inherently Harder to Read, outlines a different method for how letters and word shape work to make it easier for people to read.

In her research she found that people respond to letters they recognize and anticipate, essentially recognizing letter sequences within a word, not the shape of the word. Because of the eye's jumpy nature, thanks to saccades (great article in an old Scientific American issue), your eyes essentially leap ahead a bit and leverage peripheral vision to recognize letters and, as a result, words. A reader can generally pick up 15 letters at a time this way.

From here she argues that text set in all-caps isn't harder to read by its nature, readers just don't have much experience with it. Readers will still take longer to read it, so there is no reason to assume the difference in speed is a myth. They can be trained, however, to bring that speed up.

There is a contrary viewpoint to this, however. A dyslexic writer at the Daily Kos has posted her own plea for writers (blog commentors, etc.) to avoid using all-caps in their comments, posts, articles, etc. This writer claims that she relies on the shape of a word:

However letters mean little to me still I read by a form of pictogram system. Every word has a shape therefore I read the word by its visual form and not its content. [...] [W]hen someone writes in all caps I just cannot see the shape of the intended word [...] I know quite a few dyslexics of varying severity and know that word form is important to many.

In short, while it may be possible to train a reader to recognize all-caps, you certainly won't train your users to do it. Nor do you want to be the application, web site, book, journal, etc. that drives people away in such a misguided attempt. Even if you did manage to train your readers, you would clearly be leaving some selection of dyslexic users out in the cold, perhaps not to return (or worse, to recommend against reading to all their friends).

Architects and engineers who are used to reading all-caps may be excluded from the first part, but I am in no position to form a focus group to test that theory for the scope of this brief piece.

Read More