Hvis du er ny her, vil du kanskje abonnere på min RSS feed. Slik at du kan lese de siste oppdateringer om Web2.0 verktøy, Making Money Online, tips i SEO, Ajax og mange flere. Takk for besøket ProgramimiCOM!

En web-standarder sjekkliste

Begrepet webstandarder kan bety forskjellige ting for forskjellige folk. For noen er det table-frie områder ", for andre er det 'med gyldig kode. Men web-standarder er mye bredere enn som så. Et nettsted bygget til web-standarder bør følge standarder (HTML, XHTML, XML, CSS, XSLT, DOM, MathML, SVG etc) og følge beste praksis (gyldig kode, tilgjengelig kode, semantisk riktig kode, bruker-vennlig nettadresser etc).

Med andre ord bør et nettsted bygget til webstandarder ideelt sett være tynn, ren, CSS-basert, tilgjengelig, anvendelig og søkemotor vennlige.

Om sjekkliste

Dette er ikke en uber-sjekkliste. Det er sannsynligvis mange elementer som kan legges til. Enda viktigere, bør ikke bli sett på som en liste over elementer som må tas opp på hvert nettsted som du utvikler. Det er rett og slett en guide som kan brukes:

- Å vise bredden av web-standarder
- Som et praktisk verktøy for utviklere i produksjonsfasen av nettsteder
- Som et hjelpemiddel for utviklere som er interessert i å flytte til webstandarder

Sjekklisten

1.Quality av koden
a. Bruker stedet en riktig Doctype?
b. Har nettstedet bruker et tegnsett?
c. Har anvender Valid (X) HTML?
d. Har anvender Gyldig CSS?
e. Bruker området noe CSS hacks?
f. Bruker området unødvendige klasser eller ids?
g. Koden er godt strukturert?
h. Har nettstedet har noen ødelagte koblinger?
I. Hvordan fungerer stedet i form av fart / sideformat?
j. Har nettstedet har JavaScript-feil?

2. Grad av skille mellom innhold og presentasjon
a. Har nettstedet bruk CSS for alle presentasjon aspekter (skrifttyper, farger, padding, border etc)?
b. Er alle dekorative bilder i CSS, eller vises de i (X) HTML?

3. Tilgjengelighet for brukere
a. Er "alt" attributtene brukes for alle beskrivende bilder?
b. Bruker området relative enhetene snarere enn absolutte enheter for tekststørrelse?
c. Har noen aspekter ved utformingen pause hvis skriftstørrelsen økes?
d. Har nettstedet bruke synlig hoppe menyer?
e. Bruker området tilgjengelig former?
f. Bruker området tilgjengelig bordene?
g. Er det nok farge lysstyrke / kontraster?
h. Er fargen bare brukes til kritisk informasjon?
I. Er det forsinket respons for rullegardinmenyer (for brukere med nedsatt motorikk)?
j. Er alle linker beskrivende (for blinde brukere)?

4. Tilgjengelighet for enheter
a. Har nettstedet arbeidet akseptabelt tvers av moderne og eldre nettlesere?
b. Er innholdet tilgjengelig med CSS avslått eller ikke støttes?
c. Er innholdet tilgjengelig med bilder slått av eller ikke støttes?
d. Har nettstedet arbeide i tekst-nettlesere som Lynx?
e. Har området fungerer bra når de skrives ut?
f. Har nettstedet fungerer bra i Håndholdte enheter?
g. Har nettstedet inkluderer detaljerte metadata?
h. Har nettstedet fungerer godt i en rekke nettleservindu størrelser?

5. Basic Usability
a. Er det et klart visuelt hierarki?
b. Er overskriftsnivåer lett å skille?
c. Har nettstedet har lett å forstå navigasjon?
d. Har anvender konsekvent navigasjon?
e. Er koblinger understreket?
f. Har anvender konsekvent og aktuelle språket?
g. Har du et områdekart side og kontakt siden? Er de enkle å finne?
h. For store områder, er det et søkeverktøy?
I. Finnes det en link til hjemmesiden på hver side i området?
j. Er besøkte koblinger klart definert med en unik farge?

6. Site management
a. Har nettstedet har en meningsfull og nyttig 404-feil side som fungerer fra alle dyp i området?
b. Bruker området vennlige nettadresser?
c. Gjør arbeidet ditt webadresser uten "www"?
d. Har nettstedet har et favorittikon?

1. Quality of code

1.1 Har nettstedet bruker en riktig Doctype?
En DOCTYPE (forkortelse for "Document Type Declaration") informerer validator hvilken versjon av (X) HTML du bruker, og må vises øverst på hver nettside. Doctypes er en nøkkelkomponent i compliant nettsider: your markup og CSS, vil ikke validerer uten dem.

http://www.alistapart.com/articles/doctype/

Les mer:

http://www.w3.org/QA/2002/04/valid-dtd-list.html

http://css.maxdesign.com.au/listamatic/about-boxmodel.htm

http://gutfeldt.ch/matthias/articles/doctypeswitch.html

1.2 Har nettstedet bruker et tegnsett?
Hvis en bruker agent (for eksempel en nettleser) ikke er i stand til å oppdage tegnkodingen brukes i et web-dokument, kan brukeren bli presentert med uleselig tekst. Denne informasjonen er spesielt viktig for dem å opprettholde og utvide et flerspråklig nettsted, men erklærte tegnkodingen av dokumentet er viktig for alle å produsere XHTML / HTML eller CSS.

http://www.w3.org/International/tutorials/tutorial-char-enc/

Les mer:

http://www.w3.org/International/O-charset.html

1.3 Har nettstedet bruker Valid (X) HTML?
Gyldig kode skal gi raskere enn kode med feil. Gyldig kode skal gjøre bedre enn ugyldig kode. Nettlesere blir mer standarder-kompatibel, og det blir stadig mer nødvendig å skrive gyldig og standarder kompatibel HTML.

http://www.maxdesign.com.au/presentation/sit2003/06.htm

Les mer:

http://validator.w3.org/

1.4 Har nettstedet bruker Gyldig CSS?
Du må sørge for at det finnes ikke noe feil i enten HTML eller CSS, siden feil enten i stedet kan resultere i mislykkede dokumentet utseende.

http://www.meyerweb.com/eric/articles/webrev/199904.html

Les mer:

http://jigsaw.w3.org/css-validator/

1.5 Har nettstedet bruke CSS hacks?
I utgangspunktet hacks komme ned til personlige valg, hvor mye kunnskap du har om løsningene, de bestemte design du prøver å oppnå.

http://www.mail-archive.com/wsg@webstandardsgroup.org/msg05823.html

Les mer:

http://css-discuss.incutio.com/?page=CssHack

http://css-discuss.incutio.com/?page=ToHackOrNotToHack

http://centricle.com/ref/css/filters/

1.6 Har nettstedet bruker unødvendige klasser eller ids?
Jeg har merket at utviklere å lære nye ferdigheter ofte ende opp med god CSS, men dårlig XHTML. Nærmere bestemt tendens til HTML-koden for å være full av unødvendige divs og ids. Dette resulterer i ganske meningsløst HTML og oppsvulmet stilark.

http://www.clagnut.com/blog/228/

1.7 er koden godt strukturert?
Semantisk korrekt markup benytter HTML-elementer for sine gitte formål. Strukturert HTML har semantisk mening for et bredt spekter av bruker agenter (nettlesere uten stilark, tekst-nettlesere, PDA, søkemotorer etc.)

http://www.maxdesign.com.au/presentation/benefits/index04.htm

Les mer:

http://www.w3.org/2003/12/semantic-extractor.html

1.8 Har nettstedet har noen ødelagte koblinger?
Ødelagte koblinger kan frustrere brukere og potensielt lede kunder vekk. Ødelagte koblinger kan også holde søkemotorer skal indeksere ditt nettsted.

Les mer:

http://validator.w3.org/checklink

1.9 Hvordan fungerer stedet i form av fart / sideformat?
Ikke gjør meg litt ... Det er meldingen brukere gir oss i undersøkelsen etter undersøkelsen. Selv bredbånd brukere kan lide slow-loading blues.

http://www.websiteoptimization.com/speed/

1.10 Har nettstedet har JavaScript-feil?
Internet Explore for Windows kan du slå på en debugger som vil dukke opp et nytt vindu, og fortelle deg at det javascript feil på nettstedet ditt. Dette er tilgjengelig under Alternativer for Internett på kategorien Avansert. Uncheck "Deaktiver feilsøking i skript.

2. Grad av skille mellom innhold og presentasjon

2.1 Har nettstedet bruk CSS for alle presentasjon aspekter (skrifttyper, farger, padding, border etc)?
Bruk stilsett til å styre layout og presentasjon.

http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-style-sheets

2.2 Er alle dekorative bilder i CSS, eller vises de i (X) HTML?
Målet for webutviklere er å fjerne alle presentasjonen fra html koden, slik at det rent og semantisk korrekt.

http://www.maxdesign.com.au/presentation/benefits/index07.htm

3. Tilgjengelighet for brukere

3.1 er "alt" attributtene brukes for alle beskrivende bilder?
Gi en tekst tilsvarende for alle ikke-tekstlig element

http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-text-equivalent

3.2 Har nettstedet bruke relative enheter snarere enn absolutte enheter for tekststørrelse?
Bruk relativ snarere enn absolutte enheter i kodespråk attributtverdier og stilark eiendomsverdier.

http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-relative-units

Les mer:

http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-relative-units

http://www.clagnut.com/blog/348/

3.3 Har noen aspekter ved utformingen pause hvis skriftstørrelsen økes?
Prøv denne enkle testen. Se på nettstedet i en nettleser som støtter enkel incrementation av skriftstørrelse. Nå øker nettleserens skriftstørrelse. Og igjen. Og igjen ... Se på ditt nettsted. Har sideoppsettet fortsatt holder sammen? Det er farlig for utviklere å anta at alle går gjennom ved hjelp av standard skriftstørrelser.

3.4 Har nettstedet bruke synlig hoppe menyer?

En metode skal gis som tillater brukerne å hoppe repetitive navigation links.

http://www.section508.gov/index.cfm?FuseAction=Content&ID=12

Gruppe relaterte linker, identifisere gruppen (for user agents), og til bruker agenter gjøre det, gir en vei å omkjøringsvei gruppen.

http://www.w3.org/TR/WCAG10-TECHS/#tech-group-links

... Blind besøkende er ikke de eneste inconvenienced av altfor mange lenker i et navigasjonssystem område. Recall at bevegelseshemmede personer med dårlig adaptiv teknologi kan være fast Tabulator gjennom at morass.

http://joeclark.org/book/sashay/serialization/Chapter08.html#h4-2020

Les mer:

http://www.niehs.nih.gov/websmith/508/o.htm

3.5 Har nettstedet bruker tilgjengelige former?
Skjemaer er ikke den enkleste ting å bruke for personer med funksjonshemninger. Navigerer rundt en side med skriftlig innhold er en ting, hopper mellom skjemafelt og legge inn informasjon er en annen.

http://www.htmldog.com/guides/htmladvanced/forms/

Les mer:

http://www.webstandards.org/learn/tutorials/accessible-forms/01-accessible-forms.html

http://www.accessify.com/tools-and-wizards/accessible-form-builder.asp

http://accessify.com/tutorials/better-accessible-forms.asp

3.6 Har nettstedet bruker tilgjengelige tabeller?
For datatabeller, identifisere rad og kolonneoverskrifter ... For datatabeller som har to eller flere logiske nivåer av rad-eller kolonneoverskriftene, bruker markering for å knytte data celler og header celler.

http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-table-headers

Les mer:

http://www.bcc.ctc.edu/webpublishing/ada/resources/tables.asp

http://www.accessify.com/tools-and-wizards/accessible-table-builder_step1.asp

http://www.webaim.org/techniques/tables/

3.7 Er det nok farge lysstyrke / kontraster?
Sørg for at forgrunns-og bakgrunnsfarge kombinasjoner gir tilstrekkelig kontrast sett av noen som har farge underskudd.

http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-colour-contrast

Les mer:

http://www.juicystudio.com/services/colourcontrast.asp

3.8 Er fargen bare brukes til kritisk informasjon?
Sørg for at all informasjon som formidles med farger er også tilgjengelig uten farge, for eksempel fra kontekst eller oppmerking.

http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-colour-convey

Det er i hovedsak tre typer farger mangel, Deuteranope (en form for rød / grønn farge underskudd), Protanope (en annen form for rød / grønn farge underskudd) og Tritanope (blå / gul underskuddet-svært sjelden).

Les mer:

http://colourfilter.wickline.org/

http://www.toledo-bend.com/colourblind/Ishihara.html

http://www.vischeck.com/vischeck/vischeckURL.php

3.9 Er det forsinket respons på rullegardinmenyer?
Brukere med nedsatt motorikk kan finne rullegardinmenyer vanskelig å bruke hvis responsen er satt altfor fort.

3.10 Er alle linker beskrivende?
Link tekst bør være meningsfullt nok til å gi mening da lese ut av sammenheng - enten på egen hånd eller som del av en sekvens av koblinger. Link tekst bør også være avvisende.

http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-meaningful-links

4. Tilgjengelighet for enheter.

4.1 Har nettstedet arbeidet akseptabelt tvers av moderne og eldre nettlesere?

Før du begynner å bygge opp et CSS-basert layout, bør du bestemme deg for hvilke nettlesere som støtter og til hvilket nivå du har tenkt å støtte dem.

http://www.maxdesign.com.au/presentation/process/index_step01.cfm

4.2 Er innholdet tilgjengelig med CSS avslått eller ikke støttes?
Noen mennesker kan besøke nettstedet ditt med enten en nettleser som ikke støtter CSS, eller en nettleser med CSS avslått. I innhold er strukturert godt, vil dette ikke være et problem.

4.3 Er innholdet tilgjengelig med bilder slått av eller ikke støttes?
Noen mennesker bla nettsider med bilder slått av - særlig folk på svært langsomme tilkoblinger. Innhold bør fortsatt være tilgjengelig for disse personene.

4.4 Har nettstedet arbeide i tekst-nettlesere som Lynx?
Dette er som en kombinasjon av bilder og CSS avslått. En tekstbasert nettleser vil stole på godt strukturert innhold for å gi mening.

Les mer:

http://www.delorie.com/web/lynxview

4.5 Har nettstedet fungerer bra når de skrives ut?
Du kan ta noen (X) HTML-dokument og bare stilen den for trykk, uten å berøre markeringer.

http://www.alistapart.com/articles/goingtoprint/

Les mer:

http://www.d.umn.edu/itss/support/Training/Online/webdesign/css.html#print

4.6 Har nettstedet fungerer bra i Håndholdte enheter?
Dette er en vanskelig en å håndtere inntil håndholdte enheter konsekvent støtte deres riktig papirtype. Men noen layouter fungere bedre i dagens håndholdte enheter. Betydningen av støtte for håndholdte enheter vil være avhengig av målgrupper.

4.7 Har nettstedet inkluderer detaljerte metadata?
Metadata er maskinen forståelig informasjon for web

http://www.w3.org/Metadata/

Metadata er strukturert informasjon som er opprettet spesielt for å beskrive en ressurs. Med andre ord er metadata "data om data".

4.8 Har nettstedet fungerer godt i en rekke nettleservindu størrelser?
Det er en vanlig antakelse blant utviklere som gjennomsnittlig skjermstørrelser er økende. Noen utviklerne antar at den gjennomsnittlige skjermstørrelsen er nå 1024px bredt. Men hva om brukere med små skjermer og brukere med håndholdte enheter? Er de en del av målgruppen, og blir de vanskeligstilte?

5. Basic Usability
5.1 er det et klart visuelt hierarki?
Organisere og prioritere innholdet på en side ved hjelp av størrelse, prominence og innhold relasjoner.

http://www.great-web-design-tips.com/web-site-design/165.html

5.2 Er overskriftsnivåer lett å skille?
Bruk overskriften elementer å formidle dokumentstrukturen og bruk dem i henhold til spesifikasjonen.

http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-logical-headings

5.3 Er nettstedets navigasjonen lett å forstå?
Ditt navigasjonssystemet skal gi besøkende en anelse om hva side av området de er for tiden på og hvor de kan gå neste gang.

http://www.1stsitefree.com/design_nav.htm

5.4 Er nettstedets navigering konsekvent?
Hvis hver side på nettstedet ditt har en konsekvent stil på presentasjonen, vil de besøkende at det er enklere å navigere mellom sidene og finne informasjon

http://www.juicystudio.com/tutorial/accessibility/navigation.asp

5.5 Har nettstedet er konsekvent og riktig språk?
Bruken av klart og enkelt språk fremmer effektiv kommunikasjon. Prøver å komme over så velformulerte kan være så vanskelig å lese så dårlig skrevet grammatikk, spesielt hvis språket er ikke den besøkende hovedspråk.

http://www.juicystudio.com/tutorial/accessibility/clear.asp

5.6 Har nettstedet har et områdekart side og kontakt siden? Er de enkle å finne?
Mest site maps unnlate å formidle flere nivåer av nettstedets informasjon arkitektur. I usability tester, brukere ofte overser nettstedet kart eller ikke kan finne dem. Kompleksitet er også et problem: et kart bør være et kart, ikke et navigasjonshjelpemiddel utfordring i seg selv.

http://www.useit.com/alertbox/20020106.html

5.7 For store områder, er det et søkeverktøy?
Mens søkeverktøy er ikke nødvendig på mindre steder, og noen mennesker vil aldri bruke dem, stedsspesifikke søk verktøy lar brukerne et valg av navigasjonsmuligheter.

5.8 Finnes det en link til hjemmesiden på hver side i området?
Noen brukere liker å gå tilbake til et nettsted hjemmeside etter navigere til innhold innenfor et område. Hjemmesiden blir en base for disse brukerne, som tillater dem å omgruppere før du utforsker nytt innhold.

5.9 Er koblinger understreket?
Å maksimere oppfattet affordance av clickability, farge og understreking koblingsteksten. Brukerne skal slippe å gjette eller skrubbe siden for å finne ut hvor de kan klikke på.

http://www.useit.com/alertbox/20040510.html

5.10 Er besøkte koblinger klart definert?
Mest viktig å vite hvilke sider som de allerede har besøkt frigjør brukerne fra utilsiktet besøke de samme sidene igjen og igjen.

http://www.useit.com/alertbox/20040503.html

6. Site management

6.1 Har nettstedet har en meningsfull og nyttig 404-feil side som fungerer fra alle dyp i området?
Du har bedt om en side - enten ved å skrive inn en URL direkte inn i adressefeltet, eller klikke på en out-of-date linken og du har funnet deg selv i midten av cyberspace ingensteds. En brukervennlig nettsted gir deg en hjelpende hånd, mens mange andre vil rett og slett ikke gjøre noe, avhengig av nettleserens innebygde evne til å forklare hva problemet er.

http://www.alistapart.com/articles/perfect404/

6.2 Har nettstedet bruker vennlige nettadresser?
De fleste søkemotorer (med få unntak - nemlig Google) vil ikke indeksere sider som har et spørsmålstegn eller andre tegn (som et tegn eller likhetstegnet) i URL ... hva godt er et nettsted hvis ingen finner den?

http://www.sitepoint.com/article/search-engine-friendly-urls

En av de verste elementene i nettet fra et brukergrensesnitt standpunkt er webadressen. Men hvis de er korte, logiske og selvkorrigerende, kan webadresser være akseptabelt brukbare

http://www.merges.net/theory/20010305.html

Les mer:

http://www.sitepoint.com/article/search-engine-friendly-urls

http://www.websitegoodies.com/article/32

http://www.merges.net/theory/20010305.html

6.3 Er nettstedets URL arbeide uten "www"?
Selv om dette ikke er kritisk, og i noen tilfeller er ikke engang mulig, er det alltid godt å gi folk valget av begge alternativer. Hvis en bruker skriver inn domenenavnet uten www, og får ingen område, dette kan ulempe både brukeren og deg.

6.4 Har nettstedet har et favorittikon?

En Favorittikon er en multi-oppløsning med på nesten alle profesjonelt utviklede områder. Den Favorittikon lar webmaster for å fremme deres sted, og skape et mer tilpasset utseende i en besøkendes nettleser.

http://www.favicon.com/

Favicon er definitivt ikke kritisk. Men hvis de ikke er til stede, kan de forårsake 404 feil i loggene dine (nettsted statistikk). Nettlesere som IE vil be dem fra serveren når et område er bokmerke. Hvis en favorittikon ikke er tilgjengelig, kan en 404-feil bli generert. Derfor har en favorittikon kan kutte ned på favicon bestemt 404-feil. Det samme gjelder for en robots.txt-fil.