The value-class-pattern solves two of the three most challenging issues that microformats have encountered in their entire history: accessibility and localization.

After many long months of focused iterating (repeatedly researching, brainstorming, testing, documenting) led by Ben Ward, the value-class-pattern alpha draft is ready to use and support.

Publish and implement

Several publishers have already started using the value-class-pattern, including this blog, and some implementations have already started supporting it as well.

Everyone who publishes content marked up with microformats or develops microformats implementations such as parsers and authoring tools should take a close look at supporting the value-class-pattern in the content they are publishing and the tools they are implementing. In particular:

• If your implementation parses hCalendar, hReview, or hAtom, please implement the value-class-pattern in your parser, test it with the examples given both in the spec and the growing list of value-class-pattern examples in the wild, and add it to the list of value-class-pattern implementations.
• If your site publishes hCalendar, hReview, or hAtom, please use the value-class-pattern for your dates and times, and add your site to the growing list of value-class-pattern examples in the wild.
• If your implementation generates hCalendar, hReview, or hAtom, please generate your dates and times marked up with the value-class-pattern, and add your implementation to the list of value-class-pattern implementations.

If and when you encounter any issues or have feedback regarding the value-class-pattern, please add them to the value-class-pattern-issues and value-class-pattern-feedback pages respectively.

Major resolutions and minor revisions

The value-class-pattern has greatly addressed accessibility and authoring issues across several microformats, in particular for typical uses of dates and times. However, there are still a few open issues on specific microformats for which we are still exploring better (more semantic, more accessible) solutions, in particular the geo microformat (and property of hCard) when specified as a single hyperlink or abbreviation, and hCalendar’s dtend property when specifying a whole date (rather than a specific datetime).

With the value-class-pattern providing solutions to two out of the three biggest microformats challenges (the last of the three to be addressed in its own blog post), and resolutions to the remaining substantial open issues (e.g. as mentioned) on hCard, hCalendar, hReview, and hAtom, we will work on 1.0.1 revisions that:

• incorporate said resolved substantial issues to date
• require support of the value-class-pattern
• are edited for broader understandability and usability.

The editors of all drafts, in development, and future compound microformats should also require support of the value-class-pattern in order to encourage better accessibility in content that is marked up with microformats.

Acknowledgments

Thanks to those in the broader accessibility and internationalization communities that have kept up with their constructive criticisms, suggestions, test cases, testing, test results documentation, feedback, and overall participation. Your efforts have contributed to major improvements in microformats, and we could not have done it without you and your expertise. In particular:

• The original Web Standards Project article hAccessibility by Bruce Lawson and James Craig which provided both detailed documentation of real world concrete problems that were/are being experienced due to some uses of the abbr element with microformats, as well as several ideas for alternatives to explore. Many of those ideas formed the basis for what the microformats community spent many months investigating in depth, testing, iterating, evolving and eventually narrowing down and refining into what made it into the value-class-pattern (e.g. value-title in particular).
• Everyone who has contributed documentation of patterns, issues, brainstorms, opinions regarding the abbr element, dates, datetimes, accessibility, assistive technology, internationalization/localization, etc. to the microformats wiki. All these additions to our broader body of knowledge helped shape and refine the value-class-pattern you see today.
• In particular I want to thank James Craig for the many hours he spent extensively testing and documenting of several alternatives with screen readers.
• Personally I have very much appreciated Derek Featherstone‘s optimism regarding microformats and accessibility, consistent in-person encouragement to me and others to keep working at it, and continued positive reminding to keep in mind the broader community of those that use the Web.
• Finally, thanks to all of the authors, designers, and developers supporting microformats, especially those who continued to do so when well aware of accessiblity and other open issues, for their patience and for never giving up.

Related

• @microformats announcement of value-class-pattern
• Ben Ward’s “value-class-pattern call for implementations” post to microformats-dev.

The Web is by far the most successful medium in history for the open publishing and sharing of content. Focusing efforts to promote and enable open content on the Web first and foremost (rather than say, proprietary data warehouses and corporate databases) thus has the greatest enabling effect for open content in general.

Textual content on the Web is dominated by HTML (including XHTML of course) due to its broad reach and ease of authorship. The more we are able to use HTML as the common carrier of higher fidelity chunks of information, the more we empower and enrich the publishing and sharing of textual content.

Thus microformats are developed in line with “plain old semantic HTML” (POSH) practices and principles, that is, as valid semantic extensions to HTML. Semantic HTML by itself enables sharing open content with headings, paragraphs, and lists, etc. Microformats build upon that foundation, reusing rather than reinventing (i.e. XOXO reuses HTML for lists and nested lists for outlines, rather than inventing new tags or vocabulary), and extending only for commonly published semantics beyond HTML, such as contact information, events, reviews, episodic content, etc.

These extensions can be used to publish documents containing just one type of information for consumption by domain-specific applications (e.g. a contact list for address books, or an event list for calendaring tools), or many types intermixed and nested, embedded in a larger document that ties them all together with meaningful context such as a resume, meaning that would be lost were each type of data isolated, removed from its context, and published in its own special-purpose format silo.

Whether simple collections, or compound documents, by building on HTML, all such uses work well not only on their own, but embedded and mixed with existing web content, in a way well understood by web authors, browsers and search engines alike, in stark contrast to other methods. Finally, it is this broader reach, to existing content, authors, applications, search services, and a variety of devices, that makes textual content built on HTML even more open from a practical perspective.

Creative Commons (CC) pioneered broad awareness of the need and value of open content publishing and sharing. By providing a set of licenses that let authors clearly choose how and under what conditions to make their content freely available, CC also made it easier.

Open content is dependent on the formats used to publish it for how “open” it truly is. Open content published in a proprietary format supported only by a single-vendor proprietary application is only as open as that single-vendor chooses to make it. E.g. open content authored in Microsoft Visio and published in its default VSD format is not “open” to Macintosh users (even converters have problems). Such open content is essentially held hostage by the sole application (and the sole platform family that it runs on) that supports that format. In addition, if the sole vendor in this case chooses to stop supporting that sole application, then open content in that format becomes dead content. More on that in a future post on “data longevity“.

Content is most easily, reliably, and broadly shared when the formats used by such content are as open as possible. Truly open formats encourage the maximum amount of documentation (from syndicated blog posts to professionally published books), and interoperable implementations (from open source to proprietary for-profit) of such formats. I encourage everyone developing open standards to make them as open as possible, by taking the same steps we have taken with microformats, and thus better enabling open content, and the data portability thereof.