Semantically styling breadcrumbs—What’s wrong with » › / •? | Hacker News Reader

Semantically styling breadcrumbs—What’s wrong with » › / •?

kumpunen.com

33 pointsjimsteinhart22 comments

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.

Furthermore, if Google is capable of automatically inferring breadcrumbs, why shouldn't a screenreader software be able to do the same?

The fact that a shitty user-experience can be overcome is no excuse to go ahead and build it.

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.

If a greater than symbol as a breadcrumb separator classifies as "shitty user experience" then you must lead an incredibly pampered life.

Now you've got me curious...what kind of interface or IDE does someone who's blind use to program?

This was asked 2 weeks ago:

http://news.ycombinator.com/item?id=1842289

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?

I wonder how screen readers interpret the following:

    #breadcrumbs li:after { content: ">"; }

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.

Can you give us more info on the "Semantically Correct way to list breadcrumbs?"

I'm genuinely curious. Is there an authoritative source some where (w3c, etc)?

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.

http://html5doctor.com/nav-element/

It's more structured than text data. That's something.

So slash is the best solution out there, I guess?

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).

This seems to be something to fix and standardize in HTML5.

Reply on news.ycombinator.com