The blind are blind, not retarded. Sighted people infer the meaning of breadcrumbs from context and blind people can do the same. The ">" symbol didn't start out as being an international breadcrumb sign--it had a different meaning and was adapted to the metaphorically similar purpose of showing the relative size of subsections. There's nothing stopping blind people from making the same inference when they read "Home greater-than Articles greater-than Movie reviews".
If he thinks the blind can't figure out breadcrumbs, he'd probably spit his coffee if he saw one programming.
It's not just that it can be overcome, but it must be overcome. We each must look at these expressions as they are made, and infer what is intended by them -- it may be more awkward for a blind person, but understanding "greater than" is not fundamentally different from seeing > and inferring the meaning (though you'll lack the visual queue of an arrow-like symbol).
The article doesn't actually point to any better user experience, it just imagines one might be possible as a screen reader might be able to use his notion of "semantically correct markup" better than Google's -- even though Google is one of the only serious implementations paying attention to specifically breadcrumb-related markup.
An example from long before IDEs existed: DECtalk (a very early text-to-speech voice synthesizer from circa 1988) with the standard text editors and the command line.
On a tangent: when parsing <title>s, does Google comprehend "page < section < site" the same as "site > section > page"? Up until now, I used the former, because it reads better in squished tabs and bookmarks better—but am I losing Google juice because of that?
According to the article, Google is not recognizing a list as a breadcrumb trail, which is a shame, because that is the Semantically Correct way to list breadcrumbs.
I suppose the next best thing would be to have a CSS rule
.breadcrumb-marker { speak: none; }
but it appears, based on a little Googling, that hardly any of the aural browsers support aural CSS rules.
It's similar to using lists for menus. Breadcrumbs are a list -- a list of places that you have visited on the way to where you are.
If you buy that, then you can acknowledge such use is Semantically Correct. There may be alternatives that just as Correct or even moreso.
I believe the capitalization on the term Semantically Correct is a tongue-in-cheek acknowledgment that there is no authoritative answer to this particular question.
Semantics are almost always without authority, from what I can tell. E.g., by your definition if I write "When you go to the store can you pick up milk, butter, and toilet paper" I am being semantically incorrect, as I am using this "," thing to indicate items in a list instead of ul's and li's.
> by your definition if I write "When you go to the store can you pick up milk, butter, and toilet paper"
In the context of a human conversation, the semantics of your list are apparent. In the context of HTML, the semantics are not apparent. An absence of semantics is not the same as semantically incorrect. To my understanding, something that is semantically incorrect would be more misleading than ambiguous.
It looks like the most semantically apt of all the options Google recognises. It's easy enough to use CSS or Javasscript to display it as something else.
This seems somewhat silly - isn't the most useful part of the whole "semantic web" that machines can process it easily? I do agree that Google's implementation is rather... ad-hoc.
Hm, a > b > c is supposed to be worse than a (image) b (image) c? I disagree. The style="breadcrumb" approach also sucks (overly verbose and complicated).
If he thinks the blind can't figure out breadcrumbs, he'd probably spit his coffee if he saw one programming.