[Bug 13636] New: Missing link types

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13636

           Summary: Missing link types
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: a11y
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: gcl-0039@access-research.org
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org, public-html-a11y@w3.org


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, toolbar buttons that provide
large mouse targets for navigating, 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).

It appears that new link types can be added using RDFa or 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, it's 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. Presumably WAI-ARIA could eventually do
this, but doesn't that mean a lot of overlap between it and the link types?
Alternatively, HTML5 could simply 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. This is currently forbidden.

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)
    content-edit - link to edit the current content
    content-preview - link to preview edited content before submitting
    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

* indicates types explicitly deleted by the HTML5 Working Group.

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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 3 August 2011 20:32:30 UTC