The keywords meta was greatly abused, so search engines silently put rules in place to ignore them in many cases… this led developers to believe that they are ignored outright – my own experience with them tells me that the suggestion from SEOWorkers tool:
Professional Search Engine Optimization (SEO) Tools - SEO Workers
Is quite on the money in regards to keywords. 8 to 9 WORDS that have relevance to the actual content. It is NOT called “keyphrases”, it is NOT called “keyparagraphs” – it’s Key WORDS. SINGLE WORDS that are in your CONTENT that are important. You keep it under 128 characters, using 9 or less words delimited by commas, with single words between those commas – it still seems to be obeyed by most search engines. You vary from this, it might as well not even be in your code!
This is one that pisses me off - and plays to the willy-nilly rules changes that seem to be going on for no good reason. There’s no harm in including it (I’d be interested to see how a META, which has no rules about it’s content, would fail to validate? Using that idiotic bloated half-assed HTML 5 nonsense or something?) and if I were to exclude it, I’d probably make sure I’m sending the HTML header value just to be sure. What ‘harm’ it does in including it is beyond me, and I had it drilled into me it was more reliable than the HTML lang / xml:lang bits. Now we’re not supposed to use it? Whatever. A little consistency please? Since I’m NOT moving on to that bloated HTML 5 asshattery, I’ll keep using the same heading that’s worked JUST FINE for me over the past DECADE… thank you very much for nothing.
Cynthia’s a bit of a #DDD about that. I’ve never seen it say a single site has a “correct tab order”. Frankly, if you have to resort to tabindex, there is probably something horrendously wrong with your source order.
There’s a lot of bad advice and mis-use of them – this is why you get the dips out there saying “never use them” – unfortunately that basically flushes keyboard navigation down the toilet, particularly on handhelds where it can make a huge difference in the usability of the page. After all, handheld is pretty much who it was made for. See Opera Mobile and Opera Mini’s implementations!
I’ve gotten in the habit of making a “jumpto” menu, that is filled with accesskey links for internal navigation to the parts of my page. I hide it for my screen,projection,tv media targets, but allow it to be shown on handheld. (for the handful of handhelds that actually support it).
In Opera (desktop version is fine) open my crappy two year old and not updated personal page with the retrocomputing joke skin nobody gets the joke of…
Home - DEATHSHADOW PASCAL
… and hit shift-esc. Amazing what accesskeys and title attributes can do in browsers that actually try to support accessibility. Particularly handy if you enable the “small screen” rendering mode or strip away the CSS by switching style to “user mode”.
IT’s another of those “there’s no harm in including it, and a lot of benefit” so I really fail to see the problem with it many so called “experts” out there kvetch about. Usually it’s because they used them WRONG or had one minor conflict… At which point it ends up as bad as the “never ever use tables for anything” idiots. (see the people writing vBulletin 4 skins). Just because Trident, Gecko and Webkit based browsers are retards about supporting it, doesn’t mean Opera, Blazer, SkyFire, Bolt, Teashark or any of the dozens of other mobile browsers are… or that you shouldn’t TRY.
Though really, those are minor points compared to the true accessibility bottlenecks of crappy undersized fixed metric (aka px) fonts, crappy fixed width layouts, illegible color contrasts, and a lack of semantic markup making things like screen readers harder to use. You address those issues and get a thumbs up on those, the rest is gravy.