Commit pushed to master at https://github.com/w3c/html

https://github.com/w3c/html/commit/26232e64ea96392cc12d4879a5aa60f6f6be7cfa
updated bread-crumb nav advice

fixes  bug 22739

see feedback on updated text om twitter: https://twitter.com/tombaromba/status/379924865958289408

example of pattern used on gov.uk https://www.gov.uk/search?q=enterprise+finance+guarantee
<p class="meta crumbtrail">
      <span class="visuallyhidden">Part of </span>
      <span class="section">Citizenship</span>
      <span class="visuallyhidden">, </span><span class="subsection">Government</span>
      <span class="visuallyhidden">, </span><span class="subsubsection">Government funding programmes</span>
    </p>

Is it worth noting that, while an ordered list denotes a priority (which I think is the best fit), a nested list would be more appropriate?

Here's my thought: The list doesn't show hierarchy, it's just a list. A nested list can show the structure as well:

<ol>
 <li>Home
  <ol>
   <li>About
    <ol>
     <li>Partners</li>
    </ol>
   </li>
  </ol>
 </li>
</ol>

It would render, without CSS, as:

1. Home
  1.1. About
    1.1.1. Partners

I know it's a bunch of "number 1s," but it denotes structure that a standard numbered list cannot do.

I suspect it will also be too complex for the average web dev to tackle without a pre-built tool to handle it for them (something in a CMS, for example).

Given that these days breadcrumbs are usually fragments of the core navigation (and not actual breadcrumb trails), there is a case for using unordered lists instead. The core navigation of a site is rarely marked up using ordered lists, so it makes sense to use the same basic design pattern for the breadcrumb too.

Would it be appropriate to wrap the content for the last item in an `a` element without an `href` attribute? This would be consistent with the advice and code example in the specification for the `a` element:

"If a site uses a consistent navigation toolbar on every page, then the link that would normally link to the page itself could be marked up using an a element"

- http://www.w3.org/html/wg/drafts/html/master/text-level-semantics.html#the-a-element

The full example would then be:

  <nav aria-label="You are here">
  <ol>
  <li><a href="/">Main</a></li>
  <li><a href="/products/">Products</a></li>
  <li><a href="/products/dishwashers/">Dishwashers</a></li>
  <li><a>Second hand</a></li>
  </ol>
  </nav>

Using <nav aria-label="You are here"> in stead of starting the breadcrumb with the visible text "You are here" is less accessible in my humble opinion. Users with cognitive disabilities or people that are new to the web might finds this information useful to understand the purpose of a breadcrumb. It indicates where you are. Without the introduction, it's purpose might not be clear.

Visible text is available to all users. Aria-label will only be read with a recent combination of screenreader plus browser.

Shouldn't the <nav> element (or better yet <nav role="navigation">) only be used for the main navigation and maybe secondary navigation? Adding another <nav> adds clutter. For the same reason footers (doormats) should not be marked with <nav> either. 

http://www.w3.org/html/wg/drafts/html/master/sections.html#the-nav-element
"The footer element alone is sufficient for such cases; while a nav element can be used in such cases, it is usually unnecessary."

I thought the definition of <ol> vs <ul> was not regarding styling (ie, numbers vs bullets or other notation which could equally be applied to either) but regarding the ability for the list's elements to be reordered without impacting its meaning:

http://www.w3.org/html/wg/drafts/html/master/grouping-content.html#the-ol-element

> The ol element represents a list of items, where the items have been intentionally ordered, such that changing the order would change the meaning of the document.

With that being the case then <ol> is the correct element to use for breadcrumbs as the order is essential to its meaning.

Pertaining to hierarchical nesting of lists, this seems useless for breadcrumbs as the additional siblings are never included within a breadcrumb trail. If they were included it would be some form of sitemap.

I've put comments from 7 blind users here... I put up 3 examples with different aria-label:

"you are here"
"breadcrumb trail"
"you are here, breadcrumb trail"



http://davidmacd.com/test/breadcrumb.html

@Steve: Ben has a good point about the last li element, using an 'a' without the 'href', why is this not the case right now?

@Steve: I think Gijs has a good point that visible text is even better than an aria-label, don't you agree? So why not show two examples where the text version of 'You are here' is wrapped in a <h1>, the heading of the explicit breadcrumb nav section.

@Gijs: A nav element for breadcrumbs is a good idea because it makes sense that it is part of the HTML outline, and simple footer links are not. Do you agree?

Kind regards,

Willem-Siebe Spoelstra

Commit pushed to master at https://github.com/w3c/html

https://github.com/w3c/html/commit/1482494f6d3d12419454796c032af9251abc4773
updated breadcrumb example

after further discussion, refer to Bug 22739

Commit pushed to master at https://github.com/w3c/html

https://github.com/w3c/html/commit/90f3346fc72679b28448a5695c99d505bfc431a8
tweaked intro text for previous commit

refer to bug 22739

(In reply to github bugzilla bot from comment #11)
> Commit pushed to master at https://github.com/w3c/html
> 
> https://github.com/w3c/html/commit/90f3346fc72679b28448a5695c99d505bfc431a8
> tweaked intro text for previous commit
> 
> refer to bug 22739

i forgot to update the intro text that advised used of oredered list, have changed to just list, wheter ul/lo is sued si a reasonable author judgement I think

(In reply to Ben Barber from comment #5)
> Would it be appropriate to wrap the content for the last item in an `a`
> element without an `href` attribute? This would be consistent with the
> advice and code example in the specification for the `a` element:
> 
> "If a site uses a consistent navigation toolbar on every page, then the link
> that would normally link to the page itself could be marked up using an a
> element"
> 
> -
> http://www.w3.org/html/wg/drafts/html/master/text-level-semantics.html#the-a-
> element
> 
> The full example would then be:
> 
>   <nav aria-label="You are here">
>   <ol>
>   <li><a href="/">Main</a></li>
>   <li><a href="/products/">Products</a></li>
>   <li><a href="/products/dishwashers/">Dishwashers</a></li>
>   <li><a>Second hand</a></li>
>   </ol>
>   </nav>

sure, have added

Commit pushed to master at https://github.com/w3c/html

https://github.com/w3c/html/commit/9762a81b382cfb9b75813b4fcffca51b6d34f2ad
added example image of styled breadcrumb

related to bug 22739

In my opinion, the main purpose of the breadcrumb string is indication of the current location in the site structure, like the file path indicates the location of the file in the file system, or like the physical address indicates the actual location of the place. It can be used for navigation, too, but the main question that user expects from the breadcrumbs to answer is most likely not "Where can I get from here?", but just "Where am I?". It seems that the actual feedback from the users (see Comment 8) confirm this view. One of the blind users gives blindmicemart.com as a good usability example, although it has no navigation in breadcrumbs at all — only location indication!

I agree with Adrian (Comment 3) that semantically the best choice for the breadcrumbs is the nested list (either ordered or unordered, one item may not need numbering). It's the most natural HTML way to express that 'Second hand' subcategory (the current one) belongs to 'Dishwashers' category, which is part of 'Products' category, and so on. This choice has been there at least since 2004 (http://simplebits.com/notebook/2004/02/23/sqxii-conclusion/). It might be not much used because popular CMSs had poor support for generation. But Google recommended the nested markup (not list, but still nested) of the breadcrumbs to avoid ambiguity in the site hierarchy (https://support.google.com/webmasters/answer/185417).

But presenting the breadcrumbs as a list of same rank alternatives seems to me significantly misleading. The user (especially the blind one) might decide that "Dishwashers", "Products", and "Second hand" are separate categories (and the last one is probably empty since it's not navigable). The crucial point, that he got to the second-hand dishwashers products subcategory page (which he was looking for) is completely lost, for both humans and machines, and they all might be confused.

Comparing to this, the plain paragraph of links (as Hixie suggested) doesn't make that problem. It still reports where in the site structure the user is, in a human-readable way. It still gives the navigation option. It doesn't confuse the user. In my opinion, no semantics is less evil than wrong semantics. Calling something non-eatable "a thing" is potentially less harmful than calling it "food".

So the only problem with plain paragraph for breadcrumb strings seems to be the choice of the right separator character. As a brainstorming suggestion: what about U+220B ('contains as member', '∋') Unicode math symbol?

(In reply to Ilya Streltsyn from comment #15)
> In my opinion, the main purpose of the breadcrumb string is indication of
> the current location in the site structure, like the file path indicates the
> location of the file in the file system, or like the physical address
> indicates the actual location of the place. It can be used for navigation,
> too, but the main question that user expects from the breadcrumbs to answer
> is most likely not "Where can I get from here?", but just "Where am I?". It
> seems that the actual feedback from the users (see Comment 8) confirm this
> view. One of the blind users gives blindmicemart.com as a good usability
> example, although it has no navigation in breadcrumbs at all — only location
> indication!
> 
> I agree with Adrian (Comment 3) that semantically the best choice for the
> breadcrumbs is the nested list (either ordered or unordered, one item may
> not need numbering). It's the most natural HTML way to express that 'Second
> hand' subcategory (the current one) belongs to 'Dishwashers' category, which
> is part of 'Products' category, and so on. This choice has been there at
> least since 2004
> (http://simplebits.com/notebook/2004/02/23/sqxii-conclusion/). It might be
> not much used because popular CMSs had poor support for generation. But
> Google recommended the nested markup (not list, but still nested) of the
> breadcrumbs to avoid ambiguity in the site hierarchy
> (https://support.google.com/webmasters/answer/185417).

I don't think google cares what HTML markup is used for breadcrumbs, what it takes notice of is the microdata/RDFa attributes


> 
> But presenting the breadcrumbs as a list of same rank alternatives seems to
> me significantly misleading. The user (especially the blind one) might
> decide that "Dishwashers", "Products", and "Second hand" are separate
> categories (and the last one is probably empty since it's not navigable).
> The crucial point, that he got to the second-hand dishwashers products
> subcategory page (which he was looking for) is completely lost, for both
> humans and machines, and they all might be confused.

Feedback from actual users, so far, does not suggest its misleading
I will await further feedback from users. 
> 
> Comparing to this, the plain paragraph of links (as Hixie suggested) doesn't
> make that problem. It still reports where in the site structure the user is,
> in a human-readable way. It still gives the navigation option. It doesn't
> confuse the user. In my opinion, no semantics is less evil than wrong
> semantics. Calling something non-eatable "a thing" is potentially less
> harmful than calling it "food".
> 
> So the only problem with plain paragraph for breadcrumb strings seems to be
> the choice of the right separator character. As a brainstorming suggestion:
> what about U+220B ('contains as member', '∋') Unicode math symbol?

(in reply to Steve Faulkner, comment #16)

> I don't think google cares what HTML markup is used for breadcrumbs

It uses nesting along with itemprop="child" to express the relation of hierarchy.

> Feedback from actual users, so far, does not suggest its misleading

I still suppose that considering breadcrumbs as nothing more than just a sort of menu (especially from the software tester's point of view, not from the point of view of a person who searches actual content on the site) is already a result of misleading. Quotations from the page mentioned in comment #8 (http://davidmacd.com/test/breadcrumb.html), e.g. "Having the words spoken out telling the path in short is good", seem to be more important to me. The fact that some breadcrumbs work well as a menu still doesn't mean that they work well as breadcrumbs.

My experience in talking about breadcrumbs with people in the blind community is that very few know what a breadcrumb is or how it can help them, and the idea of "you are here" is also fairly confusing. However, once it is explained there is interest ...

I think the lack of a consistent terminology, and lack of consistent markup has contributed to all this... i tried to get a dedicated term (or role) put into aria but it was not met with much enthusiasm from the group at the time... and so here we are...

Commits pushed to CR at https://github.com/w3c/html

https://github.com/w3c/html/commit/26232e64ea96392cc12d4879a5aa60f6f6be7cfa
updated bread-crumb nav advice

https://github.com/w3c/html/commit/1482494f6d3d12419454796c032af9251abc4773
updated breadcrumb example

https://github.com/w3c/html/commit/90f3346fc72679b28448a5695c99d505bfc431a8
tweaked intro text for previous commit

https://github.com/w3c/html/commit/9762a81b382cfb9b75813b4fcffca51b6d34f2ad
added example image of styled breadcrumb