HTML5 link types, microformats and ARIA

Hi! Is this a topic we should open an HTML5 placeholder bug about?

It seems that there are quite a few link types that are not yet defined, but that probably should be in order to let accessibility aids provide standardized commands for navigating and operating web sites more easily without requiring the user to read and understand a lot of content and contextual information (e.g. voice or keyboard commands to go do the next page, style sheets that would highlight or enlarge the navigation links, etc.)

HTML WG expressed concern that these aren't widely supported, but that seems to be mostly about the <link rel> in the document header rather than marking up existing, visible links in the document body. It seems to me that (a) authors are more likely to mark up links they're already including than they are to add new, hidden links in the document header, and (b) marking up of links can be encouraged by future versions of WCAG and other accessibility guidelines, and (c) even though mainstream browsers do not expose this markup, it could and may be used by accessibility aids (e.g. speech input utilities) and browser add-ins (e.g. the Link Widgets add-in for Firefox).

I'm still trying to wrap my head around the role in this of microformats. Apparently new link types can be added as microformats after HTML5 is finalized, although I doubt they'd get as widely adopted as if they're in the primary spec. I'm even more concerned because the Microformats document states that the HTML5 Working Group explicitly decided to drop support for some link types, including index, up, first, and last (discussed at http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html), and they forbid adding them back into the list of supported microformat rel types. There may or may not be good reasons; I haven't had a chance to review all their arguments. On the other hand, the same decision page says that "these relations are already registered in the IANA link relation registry", and they seem to be, leaving me quite confused about the relationship between the IANA link relation registry, the rel microformats listed on 
microformats.org, and the link rel values listed in the HTML5 spec.

Also, as I suggested elsewhere, I think it would be good to be able to mark up things other than links in the same way, as in identifying a name as the source document or author even if there's no link to it. Is that something WAI-ARIA could eventually do? If so, isn't there a lot of overlap between it and the link types? If not, we could request they change HTML5 to allow rel attribute on a elements that don't have href attributes, so that rel could be used to annotate things other than usable links.

Some examples of real-world link types that aren't now but could potentially be standardized include (names just placeholders):

    content-feedback - link to page or email address for providing feedback on the topic of the page (e.g. to comment on the blog posting)
    content-support - link to a page or email address for support on the site or topic of the site (e.g. product support for the software discussed by the page)
    site-feedback - link to page or email address for providing feedback on the web site
    site-support - link to page or email address for getting support on the web site
    sitemap - link to a page containing a sitemap for the web site
    index - link to an index
    contact - link to a contact page (although the name has already been reserved for another purpose--a huge drawback to microformats)

    types for navigating a site or collection of related documents:
         site - a link to the home page for the web site (which may include multiple subsites or multipage documents, e.g. w3.org/)
         subsite - a link to the home page for the subsite or document collection (e.g. w3.org/WAI/)
         up* - a link to the page that is logically the parent of the current page (e.g. on http://www.w3.org/WAI/gettingstarted/Overview.html it would be a link to w3.org/WAI/)
         first* - a link to the first document
         last* - a link to the last document
         first-child - a link to the page that is the logically-first child page

    types for navigating through a document broken up into multiple pages:
         continued-first
         continued-prev
         continued-next
         continued-last

To understand the difference between links for navigating through a site or collection of documents vs. navigating through pages of a single document or article that's broken into multiple pages, consider that it's common for discussion forums, to feature one set of navigation links for going between topics (e.g. "next-in-collection"), and another set of links for going between pages of posts within the current topic (e.g. "next-in-continuation"). This could still be confusing, but we should at least consider it.

Thanks,
Greg