WN

WN (https://www.wn.se/forum/index.php)
-   Sökmotorpositionering (https://www.wn.se/forum/forumdisplay.php?f=11)
-   -   Bildrubrik istället för H1 (https://www.wn.se/forum/showthread.php?t=15384)

Micke_ 2006-08-03 10:58

Min kund vill promt använda bildrubriker som huvudrubrik istället för H1.

Hur bör man koda underliggande rubriker? Börjar man på H1 eller H2? Kan man rent av sätta <H1> runt IMG taggen?

Tips mottages tacksamt..

xpat 2006-08-03 11:19

Google ser inte en bild som en rubrik så om du kan sätta dit en underliggande rubrik med h1 så funkar det. Men varför vill kunden inte använda text till rubriker?

Kaffe 2006-08-03 11:29

En Image Replacement brukar fungera här Dave Shea (Mezzoblue) kom fram till lite resultat i sin studie: http://www.mezzoblue.com/tests/revis...e-replacement/.

Själv använder jag en Image Replacement teknik baserad på DOM-scripting, för men det är av tillgänglighetsskäl, och att slippa redundant mark-up.

Det var lite skvaller för ett tag sedan om att Google flaggar sidor som döljer innehåll via CSS, men detta gällde mestadels display: none vad jag förstod.

Man kan även lägga lägga img i h1. Men jag är inte säker på hur tungt google väger alt-attributet.

Gällande rubriknivåer börjar man i regel med h1 och stega neråt. Ett överflödigt användande av h1 skall uppenbarligen också kunna tolkas som missbruk. Enligt min modell börjar jag med h1 för sidtitel, och för varje block-element under börjar jag med h2, och stegar neråt.

Micke_ 2006-08-03 11:46

Citat:

Google ser inte en bild som en rubrik så om du kan sätta dit en underliggande rubrik med h1 så funkar det. Men varför vill kunden inte använda text till rubriker?
Han vill använda ett typsnitt som används i övrig marknadsföring.

Citat:

En Image Replacement brukar fungera här Dave Shea (Mezzoblue) kom fram till lite resultat i sin studie:http://www.mezzoblue.com/tests/revis...e-replacement/.
Intressant läsning - tackar.

Citat:

Själv använder jag en Image Replacement teknik baserad på DOM-scripting, för men det är av tillgänglighetsskäl, och att slippa redundant mark-up.
Vad är det och hur funkar det?

xpat 2006-08-03 11:50

Om man visar ett resultat för Google och ett annat för en besökare så är det cloaking. Sen är det ju inte säkert att Googles spamavdelning bryr sej om det... Men det är ett risktagande.

xpat 2006-08-03 11:51

Normalt brukar man ju skapa en grafisk profil som tillåter att man använder tillgängliga typsnitt. Är det ett typsnitt som de flesta inte har? Du kan ju styra designen på h1-taggen med CSS.

Micke_ 2006-08-03 12:03

Citat:

Normalt brukar man ju skapa en grafisk profil som tillåter att man använder tillgängliga typsnitt. Är det ett typsnitt som de flesta inte har? Du kan ju styra designen på h1-taggen med CSS.
Han gillar typsnittet väldigt mycket. Det är också ett typsnitt som man normalt inte har. Han är införstådd att det är negativt i sökop-syfte.

Kaffe 2006-08-03 12:56

Citat:

Originally posted by Micke_@Aug 3 2006, 11:46
Citat:

Själv använder jag en Image Replacement teknik baserad på DOM-scripting, för men det är av tillgänglighetsskäl, och att slippa redundant mark-up.
Vad är det och hur funkar det?

Jag har haft två lösningar på lager. Den ena är så grundläggande så den blev tråkig. Jag "injicerade" ett span-element i alla element som skulle ersättas med en bild, och använder helt enkelt Sheas slutgiltiga förslag.

Är ingen direkt javascript guru, men numera använder jag den här funktionen (JSON-notation, kräver mer eller mindre en EventHandler för att implementeras). Via den slänger vi på en CSS-klass (förutsatt att bilder har laddats in): replaced på alla element. I en CSS-regel specifikt för denna gör man sedan sin image replacement:

Javascript:
Kod:

var imageReplacement = {
        testImage : new Image,
        tmp : new Date,
        suffix : 0,
        init : function() {
 *this.suffix = this.tmp.getTime();
 *this.testImage.src = 'graphics/blank.png?'+this.suffix;
 *addEvent(this.testImage,'load',this.onload,false);
        },
        onload : function () {
 *imageReplacement.replaceThese();
        },
        replaceThese : function() {
 *this.replaceThis(document.getElementById('header').getElementsByTagName('h1'));
 *this.replaceThis(document.getElementById('content').getElementsByTagName('h2'));
        },
        replaceThis : function(objID) {
 *for (var i=0;i<objID.length;i++) { objID[i].className="replaced"; }
        }
};

CSS:
Kod:

div#header h1.replaced{background: url(../graphics/logo.png) no-repeat;display:block;height:100px;text-indent: -5000px;width:500px;}
För att använda det här scriptet behövs en bild att testa mot. Det är det testimg är där för. Om testbilden, i detta fall blank.png laddas så utförs image replacement.

För en titt på vart jag snappade upp min kod-notation: http://www.dustindiaz.com/json-for-the-masses/ och orginal-varianten av det här scriptet: http://www.quirksmode.org/dom/fir.html. Som synes så använder Koch (Quirksmode) Javascript för att implementera alla bilder. Något jag tyckte kändes fundamentalt fel. En orsak är att jag fortfarande inte sett 100% resultat på att User Agents såsom screen readers eller sökmotorer inte skulle tolka DOM-scripting. Jag har endast sett flyktiga indikationer på att vissa screen readers faktiskt tolkar javascript till en viss del.

Den lösning jag använder, och det krav jag ställer på alla image replacement lösningar är att de fungerar under följande omständigheter:
  • CSS-formaterad eller Rå text visas vid Bilder Av
  • Text visas vid CSS Av
  • Javascript av (eller i a f degraderar tillräckligt bra, vilket de gör, allting som är relaterat till IR hamnar i selectorn med en klass).
  • Kan "stängas av" för Print (samma här, man kan stänga av alla Image Replacements helt via ett print-sheet).

Enda nackdelen är att det skapar lite extra flimmer, eftersom man i regel applicerar en event på body, så scriptet ifråga väntar tills body laddat in, innan scriptet utförs. Därav flimmrar rubriker och dylikt till. Vissa kunder kan tänkas ha svårare än andra för detta.

zoran 2006-08-03 13:32

Citat:

Originally posted by Kaffe@Aug 3 2006, 11:29
Det var lite skvaller för ett tag sedan om att Google flaggar sidor som döljer innehåll via CSS, men detta gällde mestadels display: none vad jag förstod.

Men är inte det rätt så dumt då många använder display:none ifall man vill bygga css-menyer.

Kaffe 2006-08-03 13:46

Citat:

Ursprungligen postat av zoran
Citat:

Ursprungligen postat av Kaffe
Det var lite skvaller för ett tag sedan om att Google flaggar sidor som döljer innehåll via CSS, men detta gällde mestadels display: none vad jag förstod.

Men är inte det rätt så dumt då många använder display:none ifall man vill bygga css-menyer.

Jo, men det är också fullt möjligt att skriva in en rad med nyckelord i valfritt element, h1 kanske? Och sätta display: none på det. Massor av nyckelord i en tungt vägande rubrik som inte stör layouten, nämnvärt mer än att man får lite extra text att ladda ner.

Lunarstorm använder ju i o f en annan lösning, som ligger kvar i deras frameset (nu utan nyckelord):

Kod:

<div style="font-size:0px;">
 </div>

Display: none bör för övrigt inte användas för CSS-styrda menyer (såsom dropdown). Det har visats att display: none är ett CSS-attribut som gäller för Screen Readers, då den inte läser upp text som ligger i ett element med CSS-attributet display: none. Om man prioriterar tillgänglighet i det långa loppet bör man alltså undivka display: none, åtminstone om man inte definierar det i ett media-specifikt stylesheet.


Alla tider är GMT +2. Klockan är nu 17:52.

Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson