The recent formalisation of the ‘HTML split’ between the W3C and the WHATWG, is not news to those working in either group. Work continues pretty much as it has, prior to Hixie’s communication to the WHATWG.
HTML Implementation in Browsers
The reality is that browser implementation information of HTML will be similar if not the same up until the point where HTML5 is finalised at the W3C. There may be some minor differences due to the W3C spec not keeping up with changes to the WHATWG spec or points where not all browser vendors have agreed on the implementation details of a particluar feature. In the latter case it may be that the WHATWG spec or the W3C spec contains implementation information relevant to some but not all current implementations or a proposed implementation that has not actually been implemented by anybody.
It will be the case that as finalisation of HTML5 occurs at the W3C, the browser implementation information in it will become progressively out of date as new features are specced in the WHATWG HTML, implementation bugs arise and are fixed. Concurrently with the finalisation of HTML5 it is envisaged that work on HTML.next will commence at the W3C, taking HTML5 as its basis. It will likely be the case that HTML.next will mostly track the WHATWG spec on implementation details where browser vendors have indicated they intend to implement the WHATWG spec as written. This is not always the case now and will not be so in the future, for example some of the new additions to canvas contained in the WHATWG spec have not been agreed upon by browser vendors and further work is taking place between Apple and Microsoft and other stakeholders to agree upon the details, this work is occurring in the W3C HTML WG. If it is the case that the Canvas 2d context spec contains agreed upon implementation details that the WHATWG spec does not, then what should occur is the WHATWG spec changes to reflect such consensus. So let us not be fooled into thinking that the current and future specification of HTML is a one way street always leading from the WHATWG to the the W3C. So it may be that at moments in time implementation details in the current W3C HTML (whether that be HTML5 or HTML X) and WHATWG HTML diverge, but it will not be a permanent divergence unless either spec diverges from reality.
It is not the case that WHATWG spec always contains a realistic representation of what is implemented in browsers, it contains defined features that are not yet implemented by any browser even though they have been in the spec (and HTML5) for years. And it omits features implemented in browsers. The command element has been specced for years When Mozilla decided to implement the HTML5 context menu instead decided to use the unspecified (in HTML) <menuItem> element rather than implement the command element.
HTML Accessibility Implementation in Browsers
While the WHATWG claims its goal is to provide a canonical description of HTML and related technologies, it only contains a minimal description of how browsers should implement HTML support for assistive technology. The WHATWG have never shown any interest to my knowledge (note: anne van kesteren claims this is FUD, but have not seen anything from the WHATWG leadership to suggest otherwise and Hixie stated the HTML to accessibility API document was unecessary) in specifying the level of detail required for the interoperable implementation of accessible HTML. This work is being carried out at the in the W3C HTML WG as part of the ongoing HTML standardization effort. WHATWG leader Ian Hickson decided to fork HTML rather than include a link to it in the WHATWG HTML:
The W3C HTML specification includes a link to an incomplete document that contradicts this specification because of a working group decision from February 2011.
Author conformance requirements and advice
Much of the authoring conformance requirements and advice impacts the accessibility of the authored content. This is where things get less predictable. While requirements and advice in regards to HTML feature implementation in browsers is in essence dictated by what browsers will implement, how such features are to be used is not and consequently the differing HTML development processes between the W3C and the WHATWG have had most effect and will continue to do so.
To get author conformance requirements and advice on the how to use HTML into the WHATWG spec, or get it changed, you must convince Ian Hickson (Hixie). If Hixie does not agree with you it doesn’t go in or it doesn’t change. The W3C HTML working group does not work this way. You can present your arguments, research and data to the working group and whether information is added to or changed in W3C HTML is decided by the working group using a consensus process. And yes this can take longer than a simple Yay or Nay from Hixie, but I think the extra time is worthwhile.
Some examples
I have long argued that due to the almost complete lack of keyboard access to the the title attribute in browsers, the HTML specification should not include conformance requirements and authoring advice for the use of the title attribute that will result in inaccessible content. I provided information on this to the HTML WG and Hixie, (then) editor of HTML5:
- Advice in spec about annotations promotes inaccessible content
- Do not consider the title attribute as a possible conforming source for caption information for an image that lacks a text alternative
- Replace poor coding example for figure containing multiple images
Each of these proposals were considered and accepted by the HTML WG and the changes were made to HTML5 to reflect this. While at the WHATWG, Hixie, making no argument either way simply rejected the changes, resulting in further forking of HTML:
The W3C HTML specification omits a number of suggestions regarding using the
titleattribute, and makes using thetitleattribute for captions non-conforming in certain specific cases, because of a number of working group chair decisions from March 2012: first, second, third.
Now I would appreciate ANYONE explaining how the splintering of authoring conformance requirements and advice being good for anyone? Is it good for users? developers? If not then who?
Conclusion
What has recently been reported as a split has in effect been happening for some time. If all you care about is how browsers implement or are expected to implement some aspects of HTML then you have little to worry about, both W3C HTML and WHATWG HTML will include pretty much the same information over time. The locus of the HTML accessibility work will continue to be at the W3C and in the HTML WG, the specification of how browsers implement HTML to support accesssibility, will continue in the W3C HTML working group. The development of author conformance requirements and advice based on real world implementations and direct participation from users will continue in the W3C HTML WG.
Is this HTML5?
The HTML living standard still claims to be HTML5, while the HTML living standard ‘developer edition’ still calls itself “HTML5 A technical specification for Web developers”, so if you are interested in how to use HTML to provide a better, more accessible user experience, then increasingly you will be in a quandary as to which set of rules to follow and which set of rules you are actually following. I think you know which one I would suggest…
Further Reading
- Mike Smith’s (aka @sideshowbarker) personal comments on the latest WHATWG vs W3C non-news
- W3C and WHATWG finalize split on HTML5 spec, forking ‘unlikely’
- Ian Hickson: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
- Steve Faulkner: Re: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
- Ian Hickson: Re: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
- Steve Faulkner: Re: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
Comments
I don’t follow the discussion in enough detail to really understand where most of the apparent discord comes from.. However since you mentioned a couple of specific issues regarding the TITLE attribute: Yes, I guess @title contents is currently unavailable to keyboard users since you say so, and you know a lot more than me about the state of assistive technology. But isn’t this a technical issue that should and will get resolved by developers of assistive technologies? If you report some bugs to i.e. Jaws/Dolphin/NVDA developers and get them fixed, those issues are no longer problems in the HTML(5) spec?
Or is your position that HTML(5) should work harder for backwards compatibility with AT tools, say exercise the same care in trying to be compatible with legacy accessibility tools as we do to be compatible with legacy browser parsers?
Hi Hallvord,
the accessibility issues with the
titleattribute are almost exclusively down to poor implementation in browsers, nothing to do with AT. In short the title attribute content is not displayed in browsers unless using a mouse. This has been a known issue for many years. It is now compounded by the total lack of display in browsers on mobile devices. Until the input device independent display of title attribute content is supported across browsers, the HTML specification should not encourage or advise use of the title attribute in situations where it cannot be accessed by users who cannot operate a mouse. More details are available in this article: Using the HTML title attribute.My position is that author requirements and advice in HTML should reflect the current browser implemenatation realities, unless those implementations are known to be rapidly converging to align with the author requirements and advice in the spec. Otherwise we have author requirements and advice in the HTML spec that produces poor usability and accessibility. For better or worse the HTML spec (now specs) are used by authors and developers as the source of a set of rules on how to correctly use HTML, we should honour that by providing the most practical and useful information in those specs.
There is an interesting tendency at the WHATWG side to not over-spec user interface issues, as these are thought to be handled by individual browsers as they please. Problem is that browsers in many cases do not care.
The specs not giving suggestions on using certain attributes or methods that are known to be poorly accessible is one thing, another would be more explicit requirements on device independence in those specs.
As an example, no browser that I know of has an accessible implementation of drag-and-drop, including Opera that only recently added support. Even though more is needed to persuade browser vendors to include accessibility in their new features, the spec explicitly making non-accessible implementations non-conforming would be a good start. Such nuances are currently more visible at the W3C side.
Right..so if we (Opera, that is) implement “show @title tooltips on spatial/keyboard navigation” we’d be in a better place? (@title on non-activatable elements would remain inaccessible of course, but it would be a start). Wonder if we have a bug report on that.. I’ll check that in a moment.
Part of the problem is what Fabian mentions below, that a18n is a lot about UI, and the HTML spec is sort of supposed to leave UI stuff to implementors. We have the same problem with some security issues: security has a lot to do with good UI, and it can be hard to put a good and secure UI on top of an implementation of a spec that didn’t put much thought into UI issues.
d’oh – sorry to mix up i18n and a11y abbreviations – think of it as the very important topic internationalized accessibility :-p
In fact Opera should have a bug on that – I filed one on the Dragonfly toolbar buttons being meaningless as long as their title descriptions don’t show on keyboard navigation.
Titles on non-activatable elements remain tricky and as a last resort caret browsing should do the trick.
Hi Hallvord,
yes and this is what is in implemented in IE 10, any focusable element displays a tooltip on focus (including usually non interactive elements where focus is achieved using tabindex=0).