Web Development Advent Calendars for 2013

Ganesha may or may not be stealing chocolate from the advent calendar.

For a few years now web developers around the world have celebrated Saturnalia Christmas with advent calendars covering topics related to the web. Some come and go, but you'll probably recognize a few regulars on this list.

I may have missed some, so please pass them along if you know of any. For those I know are not returning, I have listed them at the end.

1. 24 Ways

24 Ways, the one that most of this think about for web development calendars, is back again. It's been going strong since 2005 and based on its history this year should have some good articles.

2. Perl Advent Calendar

Perl Advent Calendar goes all the way back to 2000 (and back then looked a bit more like a traditional advent calendar, too) and has been dispensing tips for Perl developers ever since.

3. 24 Jours de Web

24 Jours de Web is starting its second year as an advent calendar for web folk. Written in French, it is clearly primarily targeted at French speakers, but a round of Google Translate will open it up to far more readers (like me).

4. UXmas

UXmas is an advent calendar aimed at the user experience community. Coming from Australia, American readers may be thrown just a bit by the schedule. The calendar promises everything from sketches, to articles, to tools, to videos.

5. Webkrauts

Webkrauts has an all German advent calendar, and it also dates back to 2005. It covers general web topics, but being in all-German readers like me will benefit from a Google Translate version of the page.

6. 12 Devs of Xmas

12 Devs of Xmas will also start the day after Christmas and go for 12 days from then. When all the other calendars have wrapped up, you'll still have one to read. The site is silent on its return, but this tweet suggests it's gotten writers and has a plan.

7. Freelancember

Freelancember 2013 is targeted squarely at freelancers. Its daily entries will consist of downloadable gifts in the form of PDF worksheets. Think of this as less about web-tech and more about MadLibs for projects. It has last year's calendar there as well, and so far (as of December 1) I cannot tell the calendar will just be a repeat of last year.

8. Mozilla Developer Network Holidays calendar

Mozilla Developer Network Holidays calendar includes brief links to resources or demos and suggests that you can edit them (if they are MDN resources). It doesn't link to previous years, but you can just hack the URL.

9. SysAdvent

SysAdvent is targeted to systems administrators, but there is a some cross-over to web developers. It has posts dating back to 2008 (and yet I missed it in last year's collection), so there is plenty of good material there if you're too impatient to wait for each day to be revealed.

10. Web Accessibility Advent Calendar 2013

Web Accessibility Advent Calendar 2013 is in Japanese, and thanks to the wonderful powers of Google Translate, I can tell you that it is a calendar to make the talk about Web accessibility (based on this statement: Webアクセシビリティに関する話題でつくるカレンダーです。). If you know Japanese, I welcome any corrections. The site Adventar.org appears to host other advent calendars, some about web technologies, some about ramen.

Not Returning

A handful of calendars aren't returning this year (so far), but in most cases content from previous years is still available. These include Font Deck's Adfont Calendar (which also skipped 2012), the Fronteers advent calendar (in Dutch, and also skipped 2012), Web Advent (it's taking a year off), Performance Calendar, HTML & CSS Advent (this is the 2012 calendar), She Said It (no access to old calendar), 12 Days of Podcasts (or at least there is no indication on its site or Twitter).

Not Web Related

ScienceGeek Advent Calendar Extravaganza is not web-related at all, and frankly it isn't promoted nor is it tagged (although I linked to “special” since that tag had the first day and nothing else). It is, however, probably going to be neat stuff given the first day is a giant image of the Christmas Tree Cluster.

Read More

Image alt Exception Change Re-Re-Re-Requested

This post is an unexpected follow-up to my post Image alt Exception Change Re-Re-Requested (note one fewer “re-”) from June 2012. Back then, some had called into question the need for alt attributes to be required and ubiquitous on all img tags.

Well, guess what — alt is back under review.

The Web Content Accessibility Guidelines (WCAG) working group is reviewing (and soliciting feedback on) changes to determine how a page may fail WCAG Guideline 1.1 Text Alternatives, which outlines how a page uses the alt attribute for images. This also means changing the techniques authors may use to pass Level A validation for WCAG SC 1.1.1.

To simplify, the discussion is centered on allowing authors to omit alt if the author uses aria-label, aria-labelledby, or title attributes. For example, the following three examples would all be valid:

<img src="fox.png" title="Photo of a fox reading aloud from a book.">
<img src="fox.png" aria-label="Photo of a fox reading aloud from a book.">
<img src="fox.png" aria-labelledby="FoxPic">
     <p id="FoxPic">Photo of a fox reading aloud from a book.</p>

David MacDonald has already captured the arguments for and against that are already being bandied about, which I reproduce here:

Arguments for the Change

• These alternatives on the img element work in assistive technology;


• The ARIA spec says these attributes should get an accessible name in the API;


• They say it's easy to teach beginner programmers to just always use an aria-label on everything, rather than requiring a label on form fields and alt on images;


• They feel that F65 is overly strong since it can fail the entire page for a single missing alt (regardless of the validity of the rest of the page), and they would like to soften it to allow those other valid elements to carry the page;


• HTML5 allows a figure/legend combination instead of alt, so they feel WCAG will have to change F65 regardless in order to allow a figure with a legend, and that helps open the door to this discussion.

Arguments against the Change

• aria-label, aria-labelledby, and title, are not really suitable attributes for img alternative text because they imply a label or title, rather than alternate text, so they are not semantic equivalents;


• title is not well supported;


• Some feel that the ARIA spec is not in any way suggesting these as replacements to alt;


• ARIA instructs authors to use native HTML where possible, and they could not come up with viable use cases for omitting alt text;


• There are hundreds of millions of dollars invested in current evaluation tools and methodologies, and this would represent a major departure from one of the most basic accessibility conventions, one that is almost as old as the web and is the “rock star” of accessibility;


• It could cost a lot of money to change guidance to developers and muddy the waters on a very efficient current evaluation mechanism;


• When the figure/legend combination is supported by assistive technology we can amend F65, but that is a different issue and the semantics of this construct are OK for text alternatives, rather than the aria-label, aria-labelledby, and title options;


• It may cause some confidence problems to WCAG legislation because it represents a strong loosening to a fundamental Success Criteria, an unnecessary change that doesn't help the cause of accessibility, but just complicates things;


• alt is better supported;


• The alt text appears when images are turned off;


• Initial twitter feedback from the community is strongly against changing this failure.

Where You Come In

You don't have to be a part of any standards body to weigh in with your opinion. You can leave comments here and I will happily carry them back to those discussing this (even if I don't agree). You can also let me know on Twitter or you can let Steve Faulkner know, as he is one of the HTML editors.

My Opinion

It is my understanding that ARIA was intended to cover the gaps where HTML didn't already have elements or features to enable accessibility. Moving to supplant an accessibility feature that is widely understood and broadly supported with one that most web developers don't understand seems like a step backward, especially when that specification should fall away in time.

There is also the case to be made for the current status of WYSIWYG editors and code generating features of CMSes. It's taken more than a decade, but for the most part they have support for alt. It seems unlikely that these tools will implement logic to exclude alt when there are valid aria- or title attributes, so they will probably still include alt regardless.

Revisiting HTML elements and attributes is warranted and should be part of the process. We've removed oddities such as hgroup and re-instated valuable bits like time. However, I am not sure why alt seems to get an annual review when it has clear history and use cases.

My very quick responses to the arguments outlined above:

Alternatives to img work in assitive technology

I am not an AT user, so I cannot address this other than to say that it is my understanding that the alternatives work inconsistently across AT whereas alt has a far more consistent experience.

ARIA says these attributes should get an accessible name

That may very well be the case, but should itself doesn't require it.

Easier to teach aria-label on everything, rather than requiring a label on form fields and alt on images

I think there is a false dichotomy here. In modern development shops, the team making forms isn't necessarily the one placing images. Labels have a clear functional association that mirrors desktop software experiences. Alternative text for an image is not a label, though sometimes it may be considered such. This also implies the label element itself may be replaced with aria-label, which isn't the point of ARIA.

Missing alt can fail an entire page

As far as I am concerned, if your entire page fails accessibility validation because of a missing alt, then that is a valid failure. It stands to reason that some items should fail regardless of how perfect the rest of the code may be. Softening the failing power of alt can be a separate discussion, but allowing it to be bypassed seems like a blanket solution. I can't imagine an entire new building is considered accessible even though there is no ramp to bypass the front steps.

Since HTML5 allows a figure/legend combination to bypass alt…

This goes back to my original resistance to allowing any exceptions for alt. I worried that any exceptions would be used as a wedge to ultimately tearing down alt. As such, I don't consider this a valid argument. If anything, it should be used as an argument to re-examine the value of making exceptions for alt and perhaps rolling them back (counter-suit!).

Related (on this blog)

• Image alt Attributes Not Always Required in HTML5, April 19, 2011.


• More on Image alt Requirement in HTML5, May 2, 2011.


• Image alt Exception Change Re-Re-Requested, June 11, 2012.


• Still Guessing on Accessibility, January 31, 2013.

Update: November 27, 2013

It is possible for W3C non-members to post their opinions/thoughts to the Accessibility Task Force list (one of the lists where this being discussed). Source:

@patrick_h_lauke anyone can mail public-html-a11y, it just may take some time to show up on list http://t.co/sFe84xMDio :) cc @stevefaulkner

— Mark Sadecki (@cptvitamin) November 27, 2013

@chaals @patrick_h_lauke @w3c all a11y TF moderated emails are being redirected to the list as quickly as they can, w/in minutes of posting

— Mark Sadecki (@cptvitamin) November 27, 2013

All the info you need to respond (reproduced here):

• E-mail discussions taking place on the HTML Accessibility TF's W3C mailing list, public-html-a11y.


• Weekly (or less frequently, as needed) HTML Accessibility TF teleconferences with minutes distributed to HTML Accessibility TF mailing list (archive);


• Sub-group teleconferences with minutes distributed to HTML Accessibility TF mailing list;


• The HTML Accessibility TF Wiki.


• The HTML Accessibility TF may use Web-based surveys instead of email to poll group opinion.

Read More

Slides: Responsive Web Design Primer

Yesterday I had the pleasure of visiting the University at Buffalo (my alma mater) to give a presentation for its CIT professional development series. I got to talk about responsive design.

Knowing in advance that the room would have technical and non-technical users I went for a code-free presentation. One thing I learned is that code would have been useful, so if you're looking for any in here you won't find it.

I understand there is video from the event, and as soon as I have it I'll share it here as well. In the meantime, enjoy the slides without any context. Which may be more entertaining than my typically awful attempts at humor.

Responsive Design Overview for UB CIT from Adrian

Read More

Google Needs to Provide Android App Interstitial Alternative

Yesterday Matt Cutts from Google tweeted that Google search results for users on smartphones may be adjusted based on the kinds of errors a web site produces (of course I was excited):

Important: if your website has smartphone errors, we may change rankings for smartphone users: goo.gl/x8R4A #smx

— Matt Cutts (@mattcutts) June 11, 2013

Matt links to a page that outlines two examples of errors that might trigger this downgrade of a site's position in the Google search results and, right in the first paragraph, links to Google's own common mistakes page:

As part of our efforts to improve the mobile web, we published our recommendations and the most common configuration mistakes.

I think it's fair to assume that anything listed on the "Common mistakes in smartphone sites" page can negatively impact your site ranking. In particular this section on app download interstitials caught my eye:

Many webmasters promote their site's apps to their web visitors. There are many implementations to do this, some of which may cause indexing issues of smartphone-optimized content and others that may be too disruptive to the visitor's usage of the site.

Based on these various considerations, we recommend using a simple banner to promote your app inline with the page's content. This banner can be implemented using:

• The native browser and operating system support such as Smart App Banners for Safari on iOS6.


• An HTML image, similar to a typical small advert, that links to the correct app store for download.

I think it's good that Google links to the Apple article. I think it's unfortunate that Google does not link to Microsoft's own solution. If you read my blog regularly, or just follow me on Twitter, you may know that I covered both Apple's and Microsoft's app banner solution in January in the post "App Store Meta Tags."

You might also note that I stated that Google Play offers no such feature. Google, the force behind Android and the one now (or soon) penalizing sites in its search engine for app interstitials, provides no corresponding alternate solution of its own.

A great thing that Google could do for its Android users, for its search engine results, and for app developers, is to support a custom meta tag that allows web sites to promote their own Android apps in the Play store. Developers can start to replace awful Android app interstitials on web sites, users can get a cleaner experience, and site owners who can't conceive of other ways to promote their apps on their home pages can move toward something that is easier to maintain and doesn't penalize them.

I think it's nice that Google is paying attention to web devs by adjusting search results, but my ranty tweets are probably falling on deaf ears. The web would be indebted to someone who can get Google's and Android's ear on this.

Read More

My Kingdom for Decimal Alignment on Numbers

This post isn't proposing any solutions (although I do toss out a hack). This post is a rant that I hope helps influence browser makers.

Background

Much of my web work isn't for public facing web sites. Often it's for enterprise-level software that is deployed via the web and used in a web browser. I think any web developer who does anything beyond standard brochure-ware is ultimately in the same boat. Usually we need stylistic control over elements on the page that aren't typically considered exciting.

Once again I find myself working on a reporting feature for a large piece of software. Reports are typically grids (a table) made up of columns & rows with numbers, letters, icons, colors and so on. Clients are used to seeing these reports the same way they might see them in Excel, Crystal Reports, and similar tools.

These reports are formatted for quick visual scans to identify outliers and exceptions, so control over formatting is key to their effectiveness.

Example

Often these grids contain numbers of various lengths that include decimals. Often these decimal values aren't the same number of (significant) digits. Let me offer an example of wildly divergent numbers (I cannot show real client data):

Name	Number	Units
George	1,984.0	years
Arthur	42.000	?
Ray	451.0	degrees
Marie	13.51	g·cm−3
Isaac	6.67384	(× 10-11) m3 kg-1 s-2
Sergei	289.8001	billions of dollars

It's standard practice to align numbers to the right. The problem is that some numbers have decimals lengths that don't match other numbers, thereby throwing off the formatting and making the entire column harder to read than necessary. Note that the biggest number is the same length as the smallest number.

CSS to the Rescue

CSS3 has a solution. The property text-align has an option to solve our problem. It can accept a one character string as the character on which to align the text.

Not just a decimal, but a string. This is great news for languages that use a comma instead of a period for decimals. It's great news for very large or very small values where perhaps you want to align on the multiplication sign instead.

This style will allow me to align on the decimals in my example table: text-align: "." right; (the keyword after the string still keeps my numbers aligned to the right, after the decimal is factored in)

Browser Support

Now the question comes down to browser support. What browsers support it? None.

A Hack

To achieve the effect I want, I would have to split my numbers into two columns, one for the whole number and one for the decimal value. Like in this hack:

Name	Number		Units
George	1,984	.0	years
Arthur	42	.000	?
Ray	451	.0	degrees
Marie	13	.51	g·cm−3
Isaac	6	.67384	(× 10-11) m3 kg-1 s-2
Sergei	289	.8001	billions of dollars

This table isn't ideal. I have to clear out padding values, remove borders, and accept that my numbers are split. It is unnecessary work that could be avoided if the browser makers would just fully support an aspect of CSS3 that has been around for years and whose related styles already have seen support for even more years across prior CSS versions.

The extra styles, whether inline or with per-cell classes, also add to the overall page weight. HTML tables aren't exactly examples of slim mark-up to begin with, but this can bloat them even more.

This table is also an accessibility gotcha. Users with screen readers are used to a particular way tabular data is read, so this variation may not come across so clearly. Users who scale text may see odd baseline text alignment as text wrapping in other columns can throw off everything else.

It is likely that others who have needed to represent data with alignment on specific characters have just used images instead. That solution is far worse than even this hack, particularly from an accessibility perspective.

My Request to You

If you work for a browser maker, please bring this to someone's attention.

If you don't work for a browser maker, please share this (or your own examples) so that perhaps the browser makers will see there is a need, even if it's not as sexy as animations, transitions, WebGL, and so on.

Related

Even in the modern international web, the specification is sometimes too Anglo-centric, as in the case of the input type="number", which isn't as universal as hoped. You can read about the request to allow developers to set a pattern attribute on input type="number" to specify the thousand separator, decimal separator, decimal precision and if any special characters should be allowed.

There are also people calling for Mozilla to drop support for MathML, suggesting that people who don't use numbers in financial and scientific applications on a daily basis may not see the value in stronger support for number formatting.

Read More

My Presentation Slides: Making Your Site Printable

On Friday, May 17 I had the pleasure of speaking for the first time at Stir Trek, a one-day conference in Columbus, Ohio, that drew over 1,200 attendees (and I understand sold out in just a few minutes). Apparently the name is a reference to the MIX developer conference, for which they were unable to obtain license to use a variation on the name.

I also had the pleasure of presenting for the first time on best practices for making your web site printable, built from my own professional experience, my PrintShame site, and an article I wrote for .net Magazine, among other resources (also linked in the presentation).

With 40 great speakers across 8 different tracks, there was quite a lot on offer throughout the day. Considering the other presentations held at the same time as mine, I was thrilled to get any audience and more excited to see that those who attended saw value in the topic and asked great questions throughout.

As promised in the session, I have made my slides available online via SlideShare and embedded them here:

Well after the talk I got even more questions and feedback on the session, which I truly appreciated. Since there is no official survey for attendees to give feedback on a speaker, I am hoping any attendees will feel comfortable tweeting about it or leaving a comment here. So far I have gotten one great bit of feedback on Twitter:

Lest anyone think I'm just terminally negative, @aardrian had a REALLY GOOD talk on accessibility. And printability.

— David Longshore (@DavidLongshore) May 17, 2013

(I worked in some accessibility tips during my presentation.)

All other feedback is welcome (including if I was loud enough when the lavalier microphone failed).

While in Columbus I also had the pleasure of having a nice dinner (I arrived too late to make the speaker dinner), visiting the North Market, and, as part of the conference, getting to see a double feature of Iron Man 3 and Star Trek: Into Darkness. All around a good time which I look forward to repeating next year.

Read More

Balancing Act: Features, Budgets & Timelines at Web Standards Sherpa

As of today I am an author over at Web Standards Sherpa. I wrote an article discussing the process of juggling a no-budget, tight-timeframe web site for Buffalo Soccer Club while still trying to adhere to best practices. The article is titled "Balancing Act: Features, Budgets & Timelines."

I get a chance to talk about responsive design and even rant just a little bit about print styles (the article itself prints well, too). The article also has the nifty ReadSpeaker feature which means that the page can read the article aloud to you in a voice that is entirely unlike mine (at least it's a male voice by default).

Adrian offers insight into the decision process of building a new site for the Buffalo Soccer Club, a not-for-profit with little to no budget and a looming deadline. Read it…

Read More

ARIA Tabs

Last week I spent my Friday afternoon trying to get my head around how to apply ARIA properly to a tabbed interface. I even got so far as to map it out on my whiteboard and snap a photo so I could mull it over during the weekend.

And then the very next day Marco Zehe, responsible for accessibility quality assurance at Firefox, posted Advanced ARIA tip #1: Tabs in web apps and suddenly my weekend of snow shoveling turned into fiddling.

Marco's post included sample HTML for tabs and an outline of how the script to control it should function, but did not include the necessary styles or script to make it behave as tabs. Since I was marking up a tab list anyway to incorporate ARIA, I'm sharing my code here for others to try, enhance, and so on. It's also on CodePen, so you can fork it and fiddle there.

The HTML

My code has minor differences from the example. For instance, I add a return false; at the end of the event handler. I also call the function that activates the first tab at the bottom of the page, so all tabs start as un-selected and no tab panels are visible until that function fires. You can just as easily put the logic into your HTML and CSS to have one pre-selected and skip that function call altogether.

<ul class="tabList" id="tabs" role="tablist">
  <li role="presentation"><a id="tab1" href="#panel1" onclick="showTab(1);return false;" role="tab" aria-controls="panel1" aria-selected="false">Tab 1</a></li>
  <li role="presentation"><a id="tab2" href="#panel2" onclick="showTab(2);return false;" role="tab" aria-controls="panel2" aria-selected="false">Tab 2</a></li>
  <li role="presentation"><a id="tab3" href="#panel3" onclick="showTab(3);return false;" role="tab" aria-controls="panel3" aria-selected="false">Tab 3</a></li>
</ul>

<div class="tabPanels">
  <div id="panel1" role="tabpanel" aria-labelledby="tab1">
  <p>
    Nulla tincidunt pharetra tortor. In dapibus ultricies arcu. Suspendisse at purus eu est tincidunt feugiat. Praesent et sapien. Vivamus fermentum, diam vel ornare vestibulum, nibh massa imperdiet lectus, eget tincidunt urna urna nec erat. Curabitur interdum. Nam lorem nunc, posuere quis, suscipit eu, hendrerit vitae, nisi. Etiam hendrerit tincidunt felis.
  </p>
  </div>

  <div id="panel2" role="tabpanel" aria-labelledby="tab2">
  <p>
    Vestibulum id eros eu lorem tincidunt sollicitudin. Suspendisse ligula. Sed nisi magna, elementum at, ultricies in, tincidunt imperdiet, quam. Nulla semper. Suspendisse potenti. Sed sollicitudin dolor aliquet purus. Aliquam dui. Proin arcu metus, porttitor eget, pulvinar nec, molestie dapibus, ligula.
  </p>
  </div>

  <div id="panel3" role="tabpanel" aria-labelledby="tab3">
    <p>
      Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Aliquam vel erat. Vestibulum egestas purus ut felis. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus.
    </p>
  </div>
</div>

<script>
  showTab(1);
</script>

The CSS

This CSS presumes you've already set your typefaces, your page background, and everything works as you want. I have put the minimum styles to make it visually look like tabs. You may notice that I use two different selectors for both a selected tab and for a hidden tab panel. One is by a class name, the other is by the value of the appropriate aria- attribute. Use the first for broader (older) browser support and the latter if you don't care. If you do target just current browsers, then you may adjust the script below to skip writing classes.

.tabList {
  list-style-type: none;
  padding: 0;
  margin: 0 auto;
}

.tabList a {
  display: block;
  float: left;
  border: .1em solid #000;
  padding: .25em 2em;
  margin: 0 0 -1px .25em;
  border-radius: .5em .5em 0 0;
  background-color: #aaa;
}

.tabList a:link, .tabList a:visited, .tabList a:hover, .tabList a:focus, .tabList a:active {
  text-decoration: none;
  color: #000;
}

.tabList a:hover, .tabList a:focus {
  background-color: #ccc;
}

.tabList a.selected {
  background-color: #fff;
  border-bottom: 1px solid #fff;
}

.tabPanels div {
  clear: left;
  margin: 0 auto;
  padding: 1em 2em;
  border: 1px solid #000;
  border-radius: .25em;
  background-color: #fff;
  display: none;
}

.tabPanels div.selected, div[aria-hidden=false] {
  display: block;
}

.hide, div[aria-hidden=true] {
  display: none;
}

The Script

The following script toggles classes for the tabs and the tab panels, as well as adjusting the aria-selected and aria-hidden attributes. There is no keyboard functionality in it at all, but I am always willing to take some from a kind donor. As I noted above, if you use solely the aria- attribute as a CSS selector, you can drop the part that changes the class for each element.

var OpenTab;

function showTab(num) {
  try{
      if(OpenTab!=undefined){
        var OldTabID = document.getElementById('tab'+OpenTab);
        var OldPanelID = document.getElementById('panel'+OpenTab);
        OldTabID.className = '';
        OldPanelID.className = 'hide';
        OldTabID.setAttribute('aria-selected', false);
        OldPanelID.setAttribute('aria-hidden', true);
      }
      var TabID = document.getElementById('tab'+num);
      var PanelID = document.getElementById('panel'+num);
      TabID.className = 'selected';
      PanelID.className = 'selected';
      TabID.setAttribute('aria-selected', true);
      PanelID.setAttribute('aria-hidden', false);
      OpenTab = num;
  }catch(e){}
}

An Example

The following is an embedded version of the tabs on CodePen. Because of how CodePen works, you'll see a few minor differences in styles, but this is at least a functional example which you can fork and tweak.

For example, on CodePen, the function to enable the first tab must be called in the block of script itself, but I prefer to call it at the bottom of the page.

For reasons I cannot figure out, the tabs on the embedded version of this Pen do not work. Visit the tabs directly on CodePen to see them in action.

Check out this Pen!

Wrap-up

That's it, pretty simple. If you have suggestions, corrections, or are a regular AT user and can offer further insight, please feel free to share in the comments or tweet me on the Twitters.

Update, August 6, 2012

Marco Zehe, the guy who wrote the article Advanced ARIA tip #1: Tabs in web apps (which I link above) offered some adjustments to make to my sample code. In essence, dump the aria-hidden from the HTML and use the CSS style visibility: hidden; in its place. His explanation:

@aardrian That would definitely be preferred over aria-hidden, since aria-hidden is not supported by all screen readers.

— Marco Zehe (@MarcoInEnglish) August 2, 2013

@aardrian Especially older versions of JAWS, which you'll still find a lot, will ignore it.

— Marco Zehe (@MarcoInEnglish) August 2, 2013

@aardrian So use visibility: hidden; in addition to display: none;, and you should be good. Leave aria-hidden out completely.

— Marco Zehe (@MarcoInEnglish) August 2, 2013

Read More

Still Guessing on Accessibility

I have no illusions that accessibility on the web can be tricky. It's primarily tricky because of the way developers choose to implement it. Web Axe nicely sums it up:

Most people don't realize that the web IS accessible. The problem is that designers and developers break it.

— Web Axe (@webaxe) January 28, 2013

Part of the reason developers break it is because they make assumptions about disabled users. I feel there is a trend toward assuming all disabled users are blind, all blind users surf on JAWS, all JAWS users have the same version, and this version is configured in the same way for all users.

But that's nowhere near true. The spectrum of disabilities runs from cognitive impairments through physical impairments, from dyslexia to no motor control. The spectrum of vision impairment alone runs the gamut from colorblindness, to full blindness, from age-related vision loss to at-birth loss. Even from normally-sighted users in ideal lighting conditions to normally-sighted users at an awkward viewing angle with the sun on their LCD screen.

When we think of only one disability we treat all disabled users the same. When we get feedback from one user with an issue we ourselves cannot comprehend, we tend to apply it to all users. You can learn plenty one user at a time, as I did from a web developer with dyslexia and dyscalculia. But just as a focus group of one is not adequate to extrapolate to all your users, finding one user with one variant of an impairment doesn't translate to all users with all forms of disabilities.

All of this swirled around in my head as I read two well-meaning posts from two respected web developers that, both in the original post and in the comments, show a whole lot of guesswork:

• Navigation in Lists: To Be or Not To Be, January 29, 2013 by Chris Coyier.


• On Alt Text, January 30, 2013 by Jeffrey Zeldman.

I think it's great these posts were written, even if I think we should be beyond this. While I disagree with some of the arguments in the posts, and many of the arguments in the comments, you'll find that both posts lack direct feedback from the users they purport to be supporting. The comments are littered with people guessing and asserting what disabled users need, but with little to back it up.

As you read through you will find a lot of justification built around how easy it is for the developer or how the developer thinks the user wants to "view" the content.

Posts that would benefit from comments from screen reader users:
Navigation in Lists css-tricks.com/navigation-in-…
On Alt Text alistapart.com/blog/post/on-a…

— Adrian Roselli (@aardrian) January 30, 2013

As commenters with experience working with accessibility or using accessibility tools weighed in, it still felt like the other commenters and the original authors didn't quite like the answers they were hearing.

And so we are, some 20 years after the rise of the web, still guessing how to implement accessibility. As a community, we're happy to build device labs where we can let people test on every conceivable mobile device, but we aren't building the same thing for accessibility. I am fortunate to have had a good deal of experience with disabled users both in my community, among my clients, and in my personal life. I am not so sure we as a web development community can claim that.

If you do wade into the comments on both articles, I recommend you read John Foliot's comment on the A List Apart article, even if others seem to dismiss it. In the CSS Tricks article, Louis Lazaris collects a nice set of references and Léonie Watson provides a quick straw poll of users. Ultimately Chris Coyier gathers some of this feedback.

The Upshot

People are talking about these issues. These two posts provide far more handy, contextual discussion in the comments than most web developers will bother to do on their own.

Related

I've had plenty to say about the alt attribute in the past (for example, let's not call it an alt tag). But with some people asserting that alt is no longer required in HTML5, it's easier to just link to my own retelling of why that's the case in HTML5 and why I think it's a terrible idea.

• Image alt Exception Change Re-Re-Requested, June 11, 2012.


• More on Image alt Requirement in HTML5, May 2, 2011


• Image alt Attributes Not Always Required in HTML5, April 19, 2011

Update: February 1, 2013

There is a comment on the A List Apart article from Marc Drummond that outlines cases where a description in the alt attribute, in this context, is useful to users

Dennis Lembree (Web Axe) has added to the meta discussion with his post Leave Accessibility to the Experts Please. It's worth reading the whole post and the ensuing comments to get the whole picture instead of just reacting to the title.

Update: February 4, 2013

Turning the proper application of alt text into a popularity contest (ok, I know that's not quite fair, but that's how it feels to me), CSS Tricks has a poll for alt Text Usage. With no context (what else is on the page, does the graph get explained later, why use a graph if a table can do the job, etc.), it's not exactly a fair question. There are, however, a few good comments among the rest that try to set people straight.

Read More

App Store Meta Tags

Why yes, Dominos, I'd love to tap again to get your real home page to order a pizza when I could have done it right here, below your over-sized app pitch that could be done in a tiny ribbon.

This may be old news to some of you, but I haven't found a place that collects this in one spot.

One of the most offensive experience I have when surfing a site on my mobile devices is being forced to click through an advertisement for the site's app in the iTunes store (even moreso when I am surfing on a non-iOS device). There is a fair number of sites I have tapped away from because of this (I also don't expect to be served the page I came to see, but instead shunted to the mobile home page).

If yours is one of those sites, whether promoting your entire user experience or just a product, there is a less offensive way to present your pitch to users on iOS and Windows Phone.

iOS 6

Safari on iOS 6 and later devices can promote your app with a standardized banner. Essentially you stuff a custom meta tag into your page that references your App Store ID. If the user already has the app installed, then the ad becomes a launcher instead.

The code is pretty simple:

<meta name="apple-itunes-app" content="app-id=myAppStoreID, affiliate-data=myAffiliateData, app-argument=myURL">

• app-id is required and references your app's identifier.


• affiliate-data is optional and uses your iTunes affiliate string.


• app-argument is also optional and can allow users who have your app installed to jump to a specific place in your app.

More details at Apple's developer site: Promoting Apps with Smart App Banners

Windows 8

Microsoft offers a similar feature for users of Windows 8 in non-desktop mode who are also using Internet Explorer. I have not tried it, so I cannot explain how this works as the user changes modes nor how it works with the "charms" feature of Windows 8.

This code is relatively simple as well, though it requires two meta tags and supports up to five:

<meta name="msApplication-ID"content="microsoft.build.App"/>

<meta name="msApplication-PackageFamilyName"content="microsoft.build_8wekyb3d8bbwe"/>

• msApplication-ID is required and references your app's identifier.


• msApplication-PackageFamilyName is required and contains the package family name created by Visual Studio.


• msApplication-Arguments is optional and lets you pass arguments to your app.


• msApplication-MinVersion is optional and can direct users with an old version to the Windows Store.


• msApplication-OptOut< is optional and allows pages to opt out of installing the app, switching to the app, or both./li>
  

More details at Microsoft Developer Network: Connect your website to your Windows Store app (Windows)

Google Play, BlackBerry App World, Etc.

In addition to Google Play, BlackBerry App World, I looked for similar features for the Firefox OS and Ubuntu Mobile stores. I know there are other mobile platforms out there for which I did not look.

If you know of other apps tores that offer similar features, please let me know so I can update this post.

Related

There are other places where custom meta tags are used to display targeted content. One example is used for Twitter Cards and another example is used with Google News. While you can build support for them, neither Twitter nor Google is going to use them unless you have been vetted in advance.

Updated: January 29, 2013

I wrote a version of this post with an example at the Algonquin Studios blog. I'm pasting the example in here...

Real-World Example

One of our spin-off companies, SWRemote, has an app available for iPads. There is value in promoting the app to visitors of the site but not in blocking their access to the site content with a splash page or an extra click, especially if they are not on iPads. The SWRemote web site is powered by QuantumCMS (yes, I am promoting our web content management system), which makes it about 30 seconds of effort to add the necessary meta tag to the site.

Screen shot of the QuantumCMS custom meta tag screen.

If you are already a client of ours on QuantumCMS, all you have to do is choose Site Configuration from the Settings menu and pop into the Marketing tab. This is the screen that allows you to add custom meta tags. Press the Advanced button and you are off to the races. In the Name field, for this example, I just entered “apple-itunes-app” and in the Content field I provided the custom ID for the app appended to “app-id=.” As soon as I hit Save the web site was showing the app bar to visitors:

Screen shots of the SWRemote site on an iPad3 both with the app installed and without it installed, showing how the bar changes its message.

Oddly, even though the app runs on the iPad Mini, which is running iOS6, the app bar never appeared on the site when viewed on the iPad Mini. On an iPhone 5, the app bar started to appear and then disappeared — probably as the device recognized that there is no iPhone version of the app.

If/when there is an app available for Windows Phone, the process to add this feature will be the same, allowing the site to promote both apps dependent on the audience. QuantumCMS helps make the process easier, with no need to code any changes to your site templates.

Update, March 8, 2013

What he said:

I think "Download our app!" is the new "Skip intro…"

— Jeffrey Veen (@veen) March 8, 2013

Update, April 24, 2013

There is a recap of recent rants over at .net Magazine in the article "Devs rally against mobile web doorslams."

Update: June 12, 2013

Google has just announced that it may penalize sites that promote apps with those awful interstitials. Yet Google offers no solution (as you see above) for Android apps through the Google Play store. You can get more detail in my post "Google Needs to Provide Android App Interstitial Alternative."

Read More

2012 Advent Calendars for Web Devs

Now that the (Western, my favorite) holiday season is upon us, the tradition of advent calendars whose chocolate is replaced with web-related tips and articles is back. This year's crop is missing some from last year, but there's still good stuff to be found.

If you know of any others, please pass them along. For those not returning, I have listed them at the end.

1. 24 Ways

24 Ways, the one that pretty much defines the genre for me, is back again. It's been going strong since 2005 and based on its history this year should have some good articles.

2. Performance Calendar

Performance Calendar dates back to 2009 (and still defaults to 2011 if you go straight to the domain). It focuses on techniques to speed up your site via scripting, CSS, and general mark-up, along with server tweaks and analysis suggestions.

3. Perl Advent Calendar

Perl Advent Calendar goes all the way back to 2000 (and back then looked a bit more like a traditional advent calendar, too) and has been dispensing tips for Perl developers ever since.

4. Webkrauts

Webkrauts has an all German advent calendar, and it also dates back to 2005. It covers general web topics, but being in all-German readers like me will benefit from a Google Translate version of the page. Suggestion via @patrick_h_lauke.

5. 24 Jours de Web

24 Jours de Web has kicked off its first year as an advent calendar for web folk. Written in French it is clearly primarily targeted at French speakers, but a round of Google Translate will open it up to far more readers (like me). Suggestion via @PhilippeVay.

6. Japanese HTML5 Advent Calendar

HTML5 Advent Calendar 2012 is in Japanese, and thanks to the wonderful powers of Google Translate, it was very little confidence that I suggest it is produced by volunteers who have each picked a day and written something about the web (based on this statement: 登録した日に自分のブログなどにエントリーを書いてください。). If you know Japanese, I welcome any corrections. The site Adventar.org appears to host other advent calendars, some about web technologies, some not.

7. Web Advent

Web Advent is back. I had incorrectly listed it as not returning below, under its original address as the PHP advent calendar. With its name and domain change, it appears to be back again this year and keeping its streak from 2007 going strong.

8. HTML & CSS Advent

HTML & CSS Advent uses a rather self-explanatory name. Moving away from last year's advent-calendar-flap layout and to more of a list of articles, you'll find some experimentation with cutting-edge (or nearly so) features that may not make into client work just yet.

9. 12 Devs of Xmas

12 Devs of Xmas was also listed below as not returning (it has articles from last year), but I misunderstood — it will be starting the day after Christmas and going for 12 days from then. When all the other calendars have wrapped up, you'll still have one to read.

10. UXmas

UXmas is an advent calendar aimed at the user experience community. Coming from Australia, American readers may be thrown just a bit by the schedule. The calendar promises everything from sketches, to articles, to tools, to videos. Found this one via .net Magazine.

11. Freelancember

Freelancember 2012 is produced by the makers of Freckle time tracking software and targeted squarely at freelancers. Its daily entries will consist of downloadable gifts in the form of PDF worksheets. Think of this as less about web-tech and more about MadLibs for projects. Found this one via .net Magazine.

12. Mozilla Developer Network Holidays calendar

Mozilla Developer Network Holidays calendar includes brief links to resources or demos and suggests that you can edit them (if they are MDN resources). I had this one listed as non-returning because last year's address was very generic and the site has no navigation on the home page to direct users here. Perhaps that should be tip #1.

13. She Said It

She Said It is an advent calendar dedicated to providing general tips for the web industry in general, with quotes provided by women in the field. I only discovered this on Christmas Eve eve, so I've seen it fully populated by now. This calendar is produced in Sweden, but its contributors hail from everywhere.

14. 12 Days of Podcasts

12 Days of Podcasts, which I discovered on the day after Christmas, runs from December 26 to January 6, 2013. Each day will have a different audio-only interview with assorted web folks. You can stream them off the site or download the MP3 for later listening pleasure (perhaps during that terrible New Year party you're attending).

Not Returning

A handful of calendars aren't returning this year (so far), but content from previous years is still available. These include Font Deck's Adfont Calendar, and the Fronteers advent calendar (in Dutch).

Completely Unrelated

I discovered this one this morning and have no idea what to expect (other than the first day so far), but it might worth a look: Popperfont's Sciencegeek Advent Calendar Extravaganza. With such a compelling name, how can you not look?

Read More

New Main Element Approved, then Blocked

When I saw main proposed as an element a few months ago (or content or maincontent as alternate names), I didn't think the process to fold it into the HTML specification would move very quickly.

Much to my surprise on the W3C HTML Working Group mailing list the main element not only got a draft HTML5 extension specification quickly, it also worked its way through the process to become approved as a First Public Working Draft on Tuesday (yesterday) the 27^th of November.

And so the process appears to be working.

Except the W3C is just one of the standards bodies working on HTML5. There is also WHATWG, the body that years ago picked up the then-discarded HTML specification from W3C and started to carry it forward to HTML5. Now the two groups work together, with the W3C working on versioned specifications with WHATWG working on the ever-evolving standard.

Over on the WHATWG mailing list, main doesn't seem to be getting much traction from the editor, which leaves it in a bit of limbo. WHATWG does, however, try to reflect in its specification approach that which is already in place in the browsers. For example, if the browser makers suddenly supported main, then WHATWG would consider it viable.

Except WHATWG was started by, and is still made up of, people from the browser makers Apple, Mozilla and Opera. Others contribute, but its membership can heavily influence the direction browsers take.

When the author of the main extension specification started to add support for main to WebKit (the core of Apple Safari and Google Chrome), the WebKit bug report quickly turned into a fresh debate over the merit of the main element — by none other than the WHATWG editor.

Mozilla team members have pre-emptively stated that they do not support main being added to HTML5, but they did so on the WebKit mailing list. The argument against main being added as a patch to the browsers is this:

Shopping a patch to implementors, to get something into a standard spec
by asserting de-facto status based on the patch(es) landing, is bad form.

Sadly, it seems the same circular argument is being used to block main in the WHATWG HTML specification. By blocking its implementation in browsers, WHATWG members can claim there is no real-world support and so no need to add it to the specification (this is assuming the arguments against the use cases still stand). Then it's a matter of pushing back at the W3C HTML Working Group to let it wither over there.

Even the author of the use cases for the main element appears to have thrown in the towel at WHATWG.

There is still some hope, however. Both Opera and Internet Explorer representatives have not argued against it and have even offered some support:

@aardrian nothing definitive from opera but @zcorpan appered to support it and helped. got a non objection from IE at TPAC

— Steve Faulkner (@stevefaulkner) November 28, 2012

Bear in mind, all this has happened in roughly a 48 hour window. Much more will happen, but the start of this process is certainly not as positive as I had hoped (disclosure, I voted for it on the W3C list). Even if you aren't in favor of the main element, this is still a telling view into the standards-making process.

Update, January 31, 2013

And there it is, main has appeared in the WHATWG version of the HTML specification.

Read More

Chromatic Type with Pseudo Elements

Typography on the web has come a long way from the days of a handful of web-safe fonts, six sizes, and little other control. With the ability to embed custom typefaces in web pages and exert a great deal of control via CSS, it was a matter of time before old-world printing techniques for multi-colored text came to the web.

Over at Webfonts.info there is a tutorial, Layering type with CSS z-index, which shows how to achieve a multi-colored text effect by stacking the same piece of text on itself and applying a different font specifically meant for this kind of layering. The problem is that you have to duplicate the text for each layer, creating redundant text on the page that, without CSS, can look pretty odd (or sound pretty odd when read aloud by a screen reader). Discussing accessibility or SEO is outside of what I want to cover here, though.

The HTML

For my demo I am relying on CSS pseudo elements and generated content to duplicate the text for me up to two times. I also use the HTML5 data-* attribute to contain the same text value of the content itself. While I could use the title attribute, that would result in tool-tips appearing whenever you put your mouse over the text. For my demo I am using the following block of HTML:

<div>
<p class="chromatic" data-copy="Vote early &amp; vote often.">
Vote early &amp; vote often.
</p>
</div>

The CSS

I am using a new typeface family built from old wood type blocks and specifically built to be layered. More information on the typeface is at the end of this post.

Example 1: Strike Up the Band

Click/tap/select to see demo page.

This example is intended to sit on a background made up of a texture or color different than you want for the text. I use the white fill as the lowest layer, then stack the blue border on top to trap the white text and add the red stars on top from there.

div {
  position: relative;
  margin: 0; }

div p.chromatic {
  font-size: 600%;
  margin: 0;
  padding: 1em;
  position: relative;
  color: #fff;
  font-family: 'hwt_american_solidregular';  }

.chromatic::before, .chromatic::after {
  content: attr(data-copy);
  position: absolute;
  padding-right: 1em; }

.chromatic::before {
  z-index: 3;
  color: #00f;
  font-family: 'hwt_american_outlineregular'; }

.chromatic::after {
  z-index: 5;
  left: 1em;
  top: 1em;
  color: #f00;
  font-family: 'hwt_american_starsregular'; }

Example 2: That Old-Timey Feel

Click/tap/select to see demo page.

I am mimicking the mis-registration of old-timey print by off-setting the text and applying some transparency to show the texture underneath as well as the overlapping points of the "inks." I also use the distressed font for the letter fill.

When you hover over the text the alignment snaps into place, the letters become opaque, and I replace the distressed font with a solid fill.

div {
  position: relative;
  margin: 0; }

div p.chromatic {
  font-size: 600%;
  margin: 0;
  padding: 1em;
  position: relative;
  color: rgba(255,255,255,.85);
  font-family: 'hwt_american_shopwornregular'; }

.chromatic::before, .chromatic::after {
  content: attr(data-copy);
  position: absolute;
  padding-right: 1em; }

.chromatic::before {
  z-index: 3;
  color: rgba(255,51,51,.9);
  font-family: 'hwt_american_starsregular';
  margin-left: -0.02em; }

.chromatic::after {
  z-index: 5;
  left: 1em;
  top: 1em;
  color: rgba(0,0,0,.5);
  font-family: 'hwt_american_outlineregular';
  margin-top: 0.02em; }

div:hover p {
  color: rgba(255,255,255,1);
  font-family: 'hwt_american_solidregular'; }

div:hover p::before {
  color: rgba(255,0,0,1);
  margin-left: 0; }

div:hover p::after {
  color: rgba(0,0,0,1);
  margin-top: 0; }

Example 3: Accounting for Different Backgrounds

Click/tap/select to see demo page.

Here I want the text fill to be the same color as the background, which allows me to use three different colors (black for the 3D effect, blue and red). On hover I change the background color of the container, which requires me to swap the bottom layer to the fill font and set it to white.

div {
  position: relative;
  margin: 0;
  background-color: #fff; }

div:hover {
  background-color: #000; }

div p.chromatic {
  font-size: 600%;
  margin: 0;
  padding: 1em;
  position: relative;
  color: #000;
  font-family: 'hwt_american_outlineregular'; }

.chromatic::before, .chromatic::after {
  content: attr(data-copy);
  position: absolute;
  padding-right: 1em; }

.chromatic::before {
  z-index: 3;
  color: #00f;
  font-family: 'hwt_american_stars_topregular'; }

.chromatic::after {
  z-index: 5;
  left: 1em;
  top: 1em;
  color: #f00;
  font-family: 'hwt_american_stars_bottomRg'; }

div:hover p {
  color: #fff;
  font-family: 'hwt_american_solidregular'; }

Example 4: Using CSS for More Colors

Click/tap/select to see demo page.

Using some CSS drop shadows can help keep the text have more contrast with the background color or texture. On hover I turn the bottom stars red. While red usually looks terrible against blue, adding a white edge with CSS makes them stand out against the blue. It's a subtle effect that shows how you can use CSS in conjunction with chromatic typefaces to create even more effects.

div {
  position: relative;
  margin: 0; }

div p.chromatic {
  font-size: 600%;
  margin: 0;
  padding: 1em;
  position: relative;
  color: #44f;
  font-family: 'hwt_american_solidregular';
  text-shadow: 0 0 0 transparent, 0 0 0 transparent, 0 0 0 transparent, 0 0 5px #fff; }

.chromatic::before, .chromatic::after {
  content: attr(data-copy);
  position: absolute;
  padding-right: 1em; }

.chromatic::before {
  z-index: 3;
  color: #fff;
  font-family: 'hwt_american_stars_topregular';
  text-shadow: none; }

.chromatic::after {
  z-index: 5;
  left: 1em;
  top: 1em;
  color: #fff;
  font-family: 'hwt_american_stars_bottomRg';
  text-shadow: none; }

div:hover p::after {
  color: #f00;
  text-shadow: -1px -1px 0 #fff, 1px -1px 0 #fff, -1px 1px 0 #fff, 1px 1px 0 #fff; }

Example 5: Swap Fonts and CSS to Make It Pop

Click/tap/select to see demo page.

Using CSS to outline the text gives even more flexibility, so the hover effect with the 3D font and color swap makes the text pop.

div {
  position: relative;
  margin: 0; }

div p.chromatic {
  font-size: 600%;
  margin: 0;
  padding: 1em;
  position: relative;
  color: #fff;
  font-family: 'hwt_american_solidregular';
  text-shadow: -1px -1px 0 #000, 1px -1px 0 #000, -1px 1px 0 #000, 1px 1px 0 #000; }

div:hover p {
  color: #000;
  font-family: 'hwt_american_outlineregular';
  text-shadow: none; }

.chromatic::before, .chromatic::after {
  content: attr(data-copy);
  position: absolute;
  padding-right: 1em; }

.chromatic::before {
  z-index: 3;
  color: #f00;
  font-family: 'hwt_american_stars_topregular';
  text-shadow: none; }

div:hover .chromatic::before {
  color: #00f; }

.chromatic::after {
  z-index: 5;
  left: 1em;
  top: 1em;
  color: #00f;
  font-family: 'hwt_american_stars_bottomRg';
  text-shadow: none; }

div:hover .chromatic::after {
  color: #f00; }

About American Chromatic

The typeface I used for this demo is HWT American Chromatic, a collaboration between the Hamilton Wood Type & Printing Museum in Two Rivers, Wisconsin and P22 Type Foundry in Buffalo, New York. Some detail about the typeface from the readme file:

The HWT American Chromatic set is a multilayered font set that will allow for thousands of possible color and pattern combinations. The original 19th Century Chromatic that this font set is based upon included 2 fonts. The HWT digital version includes 8. The alignment isconfigured to allow any combination of the 8 fonts to all align when identical text is set and arranged, one on top of the other.

American Chromatic was originally created by Wm. H. Page & Co. circa 1857-59. It was created as a two part chromatic where portions of each color would overlap to create a third color via the blending of semi-transparent inks. Chromatic wood type was an innovative approach to the limits of the technology of the time. To print them as shown in their specimen books required a highly skilled printer.

No, I wasn't paid or given a free font family to write this.

Read More

Recent W3C HTML5 Updates

I've been a member of the W3C HTML Working Group for a month now and appear to have joined at a point when there is a push to get HTML5 wrapped up as quickly as possible. While we all (should) know that HTML5 as it is referenced in the media is really a combination of related specifications, this push is about the core HTML5 specification itself.

Be warned, this is a dry read.

The W3C HTML Working Group has been taking steps to speed the HTML5 specification to completion. A couple weeks back the chairs proposed a new plan to get HTML5 to Recommendation status in 2014 and opened it up for discussion within the group, updating a draft plan as they receive feedback. This plan gives HTML 5.0 a target date of the fourth quarter of 2014, which we can realistically assume means "by January 1, 2015." This plan also outlines a timeline for HTML 5.1, putting its release date in the fourth quarter of 2016 (by January 1, 2017).

In order to meet these timelines, HTML5 needs to make it to Candidate Recommendation by the end of this year (2012). To successfully make that goal and move on to a Proposed Recommendation, the chairs have defined "exit criteria" that must be met. To do this, from the W3C document:

[T]here must be at least two independent, interoperable implementations of each feature. Each feature may be implemented by a different set of products, there is no requirement that all features be implemented by a single product.

The exit criteria document defines independent, interoperable, and implementation, as well as the judgment level.

There are still ten open issues to be resolved to move this along. Two of the issues are to be decided by the editor, seven by the chairs and the final issue by the working group. The final issue (the first on the list) is also the only one with a due date (which has passed). The plan calls for creating extension specifications for each open issue that can potentially get folded back into the main HTML5 specification if they are put together in time (December of this year) and approved.

In addition there are still about 300 open issues and eleven Formal Objections that need to be sorted. Right now the plan pushes bugs about interoperability issues or that don't require major changes to the specification into their own group to be worked for the Candidate Recommendation phase. Remaining bugs are assigned to HTML 5.1. The 11 Formal Objections, if still supported by their authors, will be passed to the Director (Tim Berners-Lee) for "consideration."

There are a few HTML5 features at risk, meaning they might not make it into HTML5. Right now the list is short and consists of hgroup, command (and the commands API), menu, dialog, and the outline algorithm. It also includes the path object in the HTML Canvas 2D Context.

As HTML5 makes it to Last Call, the HTML Working Group Decision Policy will be updated to reflect the need to quickly resolve any open issues with a clear process to get to decisions.

For a more simplified and immediate timeline I quote the 2014 plan directly:

For CR, we begin in October 2012 by creating a draft HTML5.0
implementation report, which eliminates controversial or unstable
features, and contains a listing of all the features in the current
HTML5 specification, with information about:

• which of the features have been implemented in browsers, and in
  which browsers


• how stable each feature is


• what the level of interoperability for each feature is


• a list of at risk features

We also begin work on a systematic HTML5.0 Testing Plan, with the goals
being:

• identifying areas that are known to be inter-operable and don't need
  further tests.


• identify areas that are known not to be interoperable, and to be
  removed without the need for investing time in the creation of tests.


• 
  for the remaining areas:
  
  
  
  • systematically determine which features we currently have test
    cases for
  
  
  • systematically determine which features we still need test cases
    for
  
  
  
  

Again, as I am new to the group I am still working to understand the dynamic, the policies, the processes, and the players. I am confident, however, that we won't see HTML5 as a final specification until the start of 2015.

Part of my opinion is based on my own experience with the Working Group so far coupled with plenty of experience participating and managing mailing lists, working with clients, being involved in my community and so on.

Because I have my own assumptions on how this will all play out, I am leaving any particular opinion about any of the open items out of this post. I also suspect that, even after my short time with the W3C to date, I might be gaining a reputation (at least on Issue 30, the longdesc item) as evidenced by a random tweet:

And @aardrian takes up the good fight in the HTML5 WG lists.w3.org/Archives/Publi…

— Shelley Powers (@shelleypowers) September 21, 2012

So. There's that.

Read More