Sjekkliste for netttilgjengelighet

Tilgjengelighet er praksisen med å sikre at nettsteder er like tilgjengelige for mennesker med nedsatt funksjonsevne, slik at de har lik tilgang til varene og tjenestene nettstedene tilbyr. Det er en integrert del av profesjonell webdesign og utvikling.


Contents

Hvorfor skal du bry deg om tilgjengelighet?

Det er mange grunner til at utviklere, designere og deres arbeidsgivere / klienter bør sørge for at tilgjengeligheten er en tidlig og integrert del av prosessen med webutvikling.

  • I mange territorier, som USA, EU, Storbritannia, Israel og Japan, er det et lovkrav å ikke diskriminere mennesker på grunn av deres funksjonshemming. I USA i fjor, 2.235 nye søksmål fra ADA-nettstedet ble inngitt i føderal domstol. Det er en per time.
  • Tilgjengelige nettsteder har en tendens til å være bedre kodet, mer robuste og rangere godt på søkemotorer.
  • Tilgjengelige nettsteder har en tendens til å være det mer brukbar for ikke-funksjonshemmede besøkende, som fører til større tilfredshet og konvertering.
  • Utilgjengelige nettsteder er dårlig for bedriften. I 2019 kom a UK undersøkelse fant ut at mer enn 4 millioner mennesker forlot en detaljhandelnettsted på grunn av tilgjengelighetsbarrierer de fant. Den tapte virksomheten, ‘Click-Away Pound’, var 17,1 milliarder pund. Det er milliarder. Bare i Storbritannia.
  • Det er dårlig virksomhet å frivillig fjerne potensielle kunder.

De vanlige standardene og problemene

Heldigvis har W3C (kroppen som produserer mange av standardene som nettet stoler på) en standard for hvordan du kan gjøre nettsteder tilgjengelige. Det heter Retningslinjer for tilgjengelighet på nettet (WCAG). Det er tre konformitetsnivåer (A, AA, AAA) der ‘A’ er det laveste tilgjengelighetsnivået. Jeg anbefaler at du sikter mot nivå AA.

Dessverre er WCAG en lang, tørr og veldig teknisk lesning, så la oss se på hva du kan gjøre relativt enkelt og få det største smellet for pengene dine. Dette er ikke en sjekkliste for alt du trenger å vite; det er en sjekkliste over de vanligste feilene, og feilene som mennesker med nedsatt funksjonsevne sier er deres viktigste blokkering, med praktiske forslag for å løse problemene. Alle eksterne lenker åpnes i en ny fane.

I Click-Away Pound-undersøkelsen ble respondenter med funksjonsnedsettelser spurt om hva som var hovedblokkene for dem som fullførte kjøp. Her er toppbarrierer (flere svar var tillatt):

  1. Overfylte sider med for mye innhold – 66%
  2. reCAPTCHA tester – 59%
  3. Dårlig lesbarhet (kontrast, tekstoppsett) 56%
  4. Distraksjonen av bevegelige bilder og grafikk – 53%
  5. Dårlig lenkeinformasjon – 59% (77% for skjermleserbrukere)
  6. Skjemautfylling 56%

Hvordan forbedre nettstedets tilgjengelighet

For det første, oppmerksom på at ingen av de fem beste er tekniske problemer – det er design- eller tekstforfatterfeil.

1) For mye innhold

Kort sagt: del opp tekst i seksjoner med overskrifter og punktliste. Bruk enkelt språk.

Det er velkjent at når antallet valg øker, så gjør det også innsats som kreves for å samle informasjon og ta gode avgjørelser. Det er det samme med for mye innhold – det blir snart overveldende. Å parre innholdet til det vesentlige er et tidkrevende håndverk; som Mark Twain (angivelig) skrev: “Jeg hadde ikke tid til å skrive et kort brev, så jeg skrev et langt brev i stedet.”

Den siste boken Writing Designing antyder

Folk vil være i stand til å skumme lange blokker med tekst, uansett syn eller lyd, så det er ekstremt viktig å strukturere langformsskrivingen din med overskrifter, korte avsnitt og annen praksis for innholdsdesign..

Så:

  • Har bare en

    på en side.

  • Bruk underoverskrifter liberalt; det bryter opp en ‘plate’ tekst for seende brukere, mens brukere av hjelpemidler som skjermlesere kan bruke en snarvei-tast for å hoppe mellom overskrifter eller få et mentalt kart over innholdet fra overskriftsstrukturen..
  • Ikke hopp over et nivå på overskrifter. Hvis du for eksempel bruker en

    , sørg for at det er gitt en

    .

  • Bruk punktlister (som dette!) Merket riktig i HTML som
      ,
    • . Skjermlesere kunngjør “Liste over 10 elementer” (og lar brukeren hoppe over dem).

    Bruk vanlig engelsk

    Monzo Banks “Stemmen vår” guide forklarer viktigheten av vanlig språk:

    I 2010 kjørte den amerikanske advokaten Sean Flammer et eksperiment. Han ba 800 kretsrettsdommer om side med enten et tradisjonelt ‘legalese’ argument, eller en i det han kalte ‘vanlig engelsk’..

    Dommerne foretok overveldende den vanlige engelske versjonen (66% til 34%), og den preferansen holdt uansett alder eller bakgrunn.

    Flammer-notater (PDF) av den vanlige engelske versjonen:

    Det er kortere på nesten en side, så det fjerner åpenbart unødvendige setninger og ord. Setningene gjennomsnitt 17,8 ord, i motsetning til 25,2 ord.

    Han konkluderer med:

    Vi har nå 25 års empirisk forskning som fører til en uunngåelig konklusjon: Hvis du vil glede og overtale leseren din, skriv på vanlig engelsk.

    2) ReCAPTCHA

    Kort sagt: ikke la brukerne dine hoppe gjennom potensielt umulige bøyler for å spare tid for utviklerne.

    Respondentene snakket ofte om en gammel ReCAPTCHA-versjon:

    versjoner av reCAPTCHA med vinglete tekst som du må skrive inn på nytt

    Jeg sliter med bildene og må skrive inn tall eller bokstaver. I den typen der jeg må klikke på hvilke bilder som har en butikk eller hva som helst, savner jeg alltid noen eller blir forvirret og bruker opp energi jeg ikke har …

    Den vinglende bokstavstilen til reCAPTCHA er nå avskrevet. Det er mye mer vanlig å se en nyere inkarnasjon kalt “Ingen CAPTCHA reCAPTCHA” (også kjent som “Jeg er ikke en robot) som krever at brukeren merker av i en rute som bekrefter at de ikke er en robot, og som bruker hemmelig voodoo for å score brukeren. Hvis de passerer, er ingen ytterligere samhandling nødvendig. Men hvis de mislykkes, vil en ytterligere utfordring vises:

    Delvis skjermbilde av en captcha som krever at brukeren klikker på alle rutene som viser appelsiner

    Husk at den typen CAPTCHA som krever at en bruker klikker på alle rutene med (si) et gateskilt ikke nødvendigvis er internasjonalt. Som Terence Eden skriver, CAPTCHAs viser ikke at du er menneske – de viser at du er amerikansk.

    Den mest tilgjengelige formen for reCAPTCHA er reCAPTCHA v3 som ikke krever brukerinteraksjon, men trenger at du gjør mer arbeid for å takle besøk som mislykkes testen:

    Det er et rent JavaScript-API som gir en score, som gir deg muligheten til å ta handling i sammenheng med nettstedet ditt: for eksempel å kreve flere faktorer for godkjenning, sende et innlegg til moderasjon, eller å stryke bots som kan skrape innhold.

    3) Dårlig lesbarhet

    Kort sagt: sørg for at tekst har tilstrekkelig kontrast, er lesbar og ikke er berettiget.

    • Sørg for tilstrekkelig kontrast. En av de vanligste tilgangsblokkene på nettet er dårlig kontrast mellom tekst og bakgrunn. Retningslinjene i W3C krever et kontrastforhold på minst 4,5: 1, bortsett fra tekst i stor skala og bilder av storskala tekst som skal ha et kontrastforhold på minst 3: 1 (logoer og ‘tilfeldig’ tekst er unntatt). Det er mange verktøy som kan måle kontrastforhold for deg; min personlige favoritt er Ada Rose Cannons utmerket kontrast widget, som er et nyttig nettlesermerkemerke som fremhever områder med utilstrekkelig kontrast på siden din.
    • Har ikke overskrifter for all-capital. Det er bevis på at de er vanskeligere å lese fordi store bokstaver har samme høyde, så vi kan ikke gjenkjenne formen til vanlige ord. I tillegg vil noen skjermlesere stave grupper med store bokstaver som om de var forkortelser (som BBC, DOJ, osv.). Hvis du må ha alle overskrifter, kan du skrive dem i en normal sak i HTML-en din og transformere dem med CSS tekst-transform: store bokstaver.
    • Venstre-justert tekst. (For sider på høyre-til-venstre-språk som arabisk eller hebraisk, rett tekst.) Ikke rettferdiggjør det, da dette gjør det vanskeligere for personer med dysleksi å lese. De British Dyslexia Association sin stilguide antyder også

      Bruk sans serif-skrifter, for eksempel Arial og Comic Sans, fordi bokstaver kan virke mindre overfylte. Alternativer inkluderer Verdana, Tahoma, Century Gothic, Trebuchet, Calibri, Open Sans.

    4) Distraherende bilder og grafikk

    Kort sagt: la brukerne stoppe all bevegelse; respektere operativsysteminnstillingene; ikke spill av videoen automatisk.

    En respondent til undersøkelsen Click-Away Pound skrev,

    Nettsteder jeg pleide å bruke med lite problem, blir nå et problem, ettersom de nå tar på seg bevegelige annonser og stadig laster flere annonser når du handler.

    Det mest grunnleggende nivået på WCAG krever “For all informasjon som beveger seg, blinker eller blar som (1) starter automatisk, (2) varer mer enn fem sekunder, og (3) presenteres parallelt med annet innhold, er det en mekanisme for brukeren til å ta en pause, stoppe eller skjule den med mindre bevegelsen, blinkingen eller rullingen er en del av en aktivitet der det er viktig ”.

    Distraksjon er en irritasjon – spesielt for personer med ADHD eller andre kognitive svikt. Men bevegelse og blinking kan også forårsake anfall, så WCAG-retningslinjene krever at innhold ikke skal blinke mer enn 3 ganger i løpet av 1 sekund.

    Respekter brukerens valg for animasjoner

    Alle store operativsystemer lar brukeren uttrykke preferanser for redusert bevegelse på skjermen – kanskje fordi de har bevegelsesutløst vestibulært spektrum. Nettstedet ditt kan oppdage om brukeren har gjort dette med CSS foretrekker-redusert-motion mediesøk.

    Her tillater vi bare en knapp å animere hvis brukeren ikke har uttrykt noen preferanse:

    @media (foretrekker redusert bevegelse: ingen preferanse) {
    knapp {
    / * `vibrere` nøkkelrammer er definert andre steder * /
    animasjon: vibrerer 0.3s lineær uendelig begge deler;
    }
    }

    Hvis du ønsker å ettermontere et nettsted som har mange animasjonsregler, kan følgende gjøre det stopp alle tidligere erklærte CSS-animasjoner:

    @media (foretrekker redusert bevegelse: redusere) {
    *,
    *::før,
    *::etter {
    animasjon-varighet: 0.001s! viktig;
    overgangsvarighet: 0.001s! viktig;
    }
    }

    I emnet å respektere brukerens preferanser for operativsystemet, kan det være lurt å vurdere designe nettstedet ditt for mørk modus.

    5) Dårlig koblingsinformasjon

    Kort sagt: gjør koblinger identifiserbare, med unik lenketekst. Advarsel brukere hvis en kobling vil åpne en ny fane eller en fil.

    En av hovedårsakene til dårlige lenker er ofte dårlig tekstforfatter. De fleste skjermlesere lar brukeren raskt se en liste over lenker på en side (i den mest brukte kommersielle skjermleseren, JAWS, er snarveien Ins + F7; i gratis NVDA skjermleser, den samme hurtigtasten bringer opp en Elements List som viser sidekoblinger, overskrifter og landemerker).

    Imidlertid, hvis hver lenke har tekst som sier “Klikk her” eller “Les mer”, uten noe annet å skille dem, er dette ubrukelig. Den enkleste måten å løse dette på er ganske enkelt å skrive unik linktekst, men hvis det ikke er mulig, kan du overkjøre lenkteksten for hjelpende teknologi ved å bruke en unik aria-label attributt på hver lenke.

    Her er et godt eksempel fra Joomla nettsted:

    Joomla nettsted, viser to forskjellige historier, hver med identiske

    Den synlige lenketeksten er ganske enkelt “les mer”, men Joomla bruker aria-etikett attributter for å gjøre hver og en unik for hjelpemidler:

    Les mer
    
    Les mer

    På grunn av aria-etikett tekst vil bli brukt i stedet for lenketeksten av hjelpemiddelteknologier, W3C anbefaler at du starter teksten som brukes i aria-etikett med teksten som er brukt i lenken, da “dette vil tillate jevn kommunikasjon mellom brukere”.

    Merk: Noen dårlige råd som jeg fremdeles ser på gamle nettsteder er å legge til forklarende tekst på lenker ved å bruke tittel Egenskap:

    Les mer>

    Ikke gjør dette. De tittelen blir ikke utsatt for de fleste skjermlesere (utviklere pleide å fylle det med nøkkelord for “SEO” -formål, slik at leverandører av skjermlesere deaktiverte det som standard), og nettlesere presenterer tittelattributter som “verktøytips” som bare er tilgjengelige for musbrukere på svevet..

    Koblinger skal se ut som koblinger

    Som standard understreker nettlesere koblinger. Det er best å ikke endre dette, men hvis du taper en kamp på parkeringsplassen med designeren om dette, må koblingsteksten ha et kontrastforhold på 3: 1 fra den omkringliggende ikke-linkteksten og skal gi noen ikke-fargebetegnende ”At de er en kobling når de blir svevet eller fokusert, for eksempel:

    a: sveve, en: fokus {tekstdekorasjon: understrek;}

    Fokusstilen gjør at koblingen blir understreket når en ikke-mus bruker fokuserer på den fra tastaturet, pekepinnen eller stemmetastingen. Generelt sett, når noe på en side har en svevetype, bør det også gis en fokusstil.

    Den “ikke-fargebetegnende” (i vårt tilfelle en understreking) sikrer at besøkende med lite syn eller fargeblindhet vil se endringen på svevet eller fokus. (Skjermlesere kunngjør automatisk “Link” før lenketekst.)

    Fortell folk om link åpner en ny fane / side

    Det kan være forvirrende for en besøkende hvis aktivering av en lenke åpner en ny fane eller et nytt vindu, spesielt hvis bare noen lenker på en side gjør dette (for eksempel er det bare eksterne koblinger som åpner en ny fane). Hvis du må gjøre dette, bør du varsle brukeren enten i lenketeksten, eller bruke aria-etikettmetoden ovenfor.

    Fortell folk om kobling er til en fil

    Hvis en kobling er til en fil (for eksempel en PDF eller en video), må du fortelle brukeren i koblingsteksten. Ikke legg skjul på det aria-etikett, ettersom dette kan være nyttig for mange seende brukere (noen mobiler kan for eksempel ikke åpne en .docx-fil). Hvis det er en stor fil, kan du vurdere å varsle brukeren om omtrentlig størrelse; de ønsker kanskje ikke å laste ned en stor videofil over 3G.

    Du kan også bruke nedlasting attributt, som får nettleseren til å åpne operativsystemets dialogboks for nedlasting av innfødt fil. Når alt dette settes sammen, vil koden se slik ut:

    Årsrapport (PDF, 240 MB)

    6) En annen designfeil: Fjerne fokusringen

    Kort sagt: sørg for at en tastatbruker alltid kan se hvor de er fokusert.

    Vi har nevnt :fokus stiler før. De er en uvurderlig visuell indikator for de menneskene som ikke kan bruke en mus av en eller annen grunn: kanskje de har RSI, eller Parkinsons eller multippel sklerose. Som standard viser nettlesere en fokusring på elementet som for øyeblikket er fokusert. Her er Hjem-lenken på mitt personlige nettsted, fokusert i en Chromium-nettleser:

    Skjermbilde av Chromiums standardfokusring rundt en lenke (som også er et bilde)

    Imidlertid anser noen dette for å være estetisk misfornøyde når de bruker en mus og slår den av med CSS, og dermed lar nettstedet være utilgjengelig for tastaturbrukere.

    Skriv inn en ny standard, pioner av Firefox, kalt : Fokus synlig. Dette vil bruke en fokusering på et element hvis det er nådd av et tastatur eller en ikke-musepekerenhet, men ikke viser noe for musebrukere. Ettersom det bare støttes i Firefox (i skrivende stund), Patrick Lauke antyder følgende CSS for å spille fint med alle nettlesere:

    knapp: fokus {/ * noen spennende knappefokusstiler * /}
    knapp: fokus: ikke (: fokus-synlig) {
    / * angre alle de ovennevnte fokuserte knappestilene
    hvis knappen har fokus, men nettleseren ikke ville normalt
    vis standard fokusstiler * /
    }
    knapp: fokusvis synlig {/ * noen enda * mer * spennende knappefokusstiler * /}

    7) Skjemautfylling

    I korte trekk: utform skjemafelt som ser ut som skjemafelt, hver assosiert med en etikett. Ikke deaktiver automatisk utfylling.

    Gitt skjemaets vitale betydning for e-handelsnettsteder, overrasker det meg hvor mange utilgjengelige skjemaer jeg ser. Ofte er det fordi gamle nettlesere ikke tillot mye i veien for styling av formelementer, så utviklere forfalsket dem med andre HTML-elementer. Moderne nettlesere tillater attraktive avkrysningsbokser, radioknapper, tilpassede utvalgte komponenter og kombinasjonsbokser, tilgjengelige autokomplette kontroller og mer.

    Autofill er din venn

    Å la nettlesere automatisk fylle ut skjemaer krever at besøkende gjør mindre, så det er mer sannsynlig at de fyller ut et skjema og registrerer / kjøper produktet ditt. Autofyll på nettlesere: Et dypdykk er en flott artikkel av eBay om dette (og de burde vite).

    I tillegg er autofullfør den eneste tilstrekkelige teknikken for å oppnå AA-samsvar med Suksesskriterium 1.3.5: Identifiser innsatsformål.

    Få skjemafelt til å se ut som skjemafelt

    Som standard viser nettlesere skjemainputfelt som bokser. Styl disse med marginer, polstring og kanter, men hold dem som bokser. Mange designere fulgte Googles materialdesignmønster for 2017 med å bruke en enkelt linje for brukeren å legge inn tekst:

    Gamle materialinnsatsinnganger, med horisontal linje fremfor rektangulær boks

    Imidlertid fant Google ut at linjen under de gamle tekstfeltene ikke var tydelig for noen brukere, ofte forvekslet med en skillelinje, og endret design. I en brukbarhetstest med 600 deltakere, oppdaget de det

    lukkede tekstfelt med en rektangulær form (boks) presterte bedre enn de med linjefordel … I dag vises disse nye tekstfeltene på tvers av Google-produkter fra påloggingssider til kontoer til Google.

    Hvis du vurderer å ta i bruk Googles fullstendige Material Design UI-bibliotek, kan du lese Slutt å bruke tekstfelt for Material Design! av Matsuko Friedland for å se om det tilfredsstiller dine behov.

    Merk alle formfelt

    Alle skjemafelt (tekstinnganger, avmerkingsbokser, radioknapper, skyvekontroller osv.) Må merkes. Den beste måten å gjøre dette på er å bruke en HTML ; som WCAG sier, “standard HTML-kontroller oppfyller allerede dette suksesskriteriet når det brukes i henhold til spesifikasjonen”.

    Her er en demo jeg laget av en umerket formfelt vs et merket skjemafelt. De ser identiske ut, men den øverste har ikke en ordentlig etikett, mens den andre gjør det. Klikk inn i tekstetiketten til den nederste, så ser du at den fokuserer på den tilknyttede inndata.

    falsk vs ekte etikett sammenligning

    Dette gjør fokusering av innspill mye enklere for noen som har vanskeligheter med motorstyring – eller kanskje for deg som prøver å sjekke en liten avkrysningsboks på en liten skjerm på et humpete tog. Det er også viktig for brukere av skjermlesere som vil bla gjennom felt i et skjema (som standard er det bare koblinger og skjemafelt som kan fokuseres ved å tappe); når de taster inn i et inputfelt, vil skjermleseren kunngjøre innholdet på den tilhørende etiketten.

    Koden for dette er enkel. Inngangsfeltet får en unik ID, og ​​etiketten er assosiert med det ved å bruke til Egenskap:

    
    

    Skjuletiketter

    Noen ganger vil du kanskje ikke ha en synlig etikett. Eller designeren gjør det ikke, og du vil ikke ha en ny kamp på parkeringsplassen. Uansett, her er et eksempel når en etikett som sier “Søk” foran innspillet føles som overdreven.

    Inntastingsfelt, med knappen merket 'søk' etterpå

    Vi kan knytte inndatafeltet til teksten “Søk”, som er innholdet på innsenderknappen ved å bruke aria-labelledby:

    
    

    Vi kunne ha brukt aria-etikett (som vi møttes tidligere når vi snakket om lenker):


    Men det er alltid bedre å foretrekke synlig tekst på en side fordi den blir oversatt hvis siden blir kjørt gjennom et oversettelsesverktøy, mens tekst “skjult” i HTML-attributter ikke vil være det. (Hat-tips til Adrian Roselli for dette tipset, fra den fantastiske artikkelen hans Min prioritering av metoder for merking av en kontroll.)

    Vanligste feil på topp millioner hjemmesider

    Vi har sett på de viktigste hindringene for e-handelsnettsteder som rapportert av brukere med en eller annen form for svekkelse. La oss se på et mye bredere sett med nettsteder – hjemmesidene for de topp 1 000 000 nettstedene, automatisk analysert av WebAIM i august 2019. 98% av sidene som ble analysert hadde minst en feil. De vanligste feilene er

    1. Tekst med lav kontrast (86,1%)
    2. Manglende alternativ tekst for bilder (67,9%)
    3. Tomme lenker (58,9%)
    4. Manglende skjemainputetiketter (53,2%)
    5. Manglende dokumentspråk (30,5%)

    Vi har behandlet lav kontrast, koblinger og skjemainnganger ovenfor. La oss se på hvordan vi kan unngå andre veldig vanlige feil.

    8) Gi tekstalternativer for alle bilder, video og lyd

    Kort sagt: all informasjon som formidles gjennom et bilde eller en video, må ha en tekstlig ekvivalent.

    Hver må ha alternativ tekst (“alt-tekst”) som kan formidles til besøkende med synshemminger eller de med lav båndbredde / dyre dataplaner som har slått av bilder i nettleserne. Dette inkluderer bilder av tekst.

    Her er de grunnleggende reglene:

    • Hvis bildet er rent dekorativt, må det ha tom alt-tekst: alt = "". (Men rent dekorative bilder burde nok være i CSS, uansett.)
    • Hvis et bilde er beskrevet i brødtekst, skal det ha tom alt-tekst (alt = ""), for å unngå repetisjon. Men vær forsiktig hvis det er et i en
      – se Hvordan regner du? for mer.
    • Hvis et bilde er det eneste innholdet i en kobling (for eksempel kan logoen til organisasjonen din klikkes for å gå til hjemmesiden), skal den alternative teksten beskrive destinasjonen til lenken. For eksempel, alt = "hjemmeside".
    • Ikke bruk ikonfonter; de kan være veldig dårlige for dyslektikere. Hvis du bruker dem, konverter dem til SVG.

    Alternativ tekst til video og lyd

    Ikke glem at lydinnhold trenger alternativ tekst for mennesker med hørselshemming. Det betyr utskrifter av podcaster, og teksting på videoer. Og igjen: ikke spill medier automatisk.

    9) Legg til riktig dokumentspråk

    I korte trekk: la hjelpeteknologi kjenne språket som teksten din er i.

    30% av hjemmesidene erklærer ikke språket de er skrevet på, noe som kan gjøre dem forvirrende for skjermleserbrukere. Dette er viktig fordi ordet “seks” uttales veldig forskjellig hvis setningen for eksempel er på engelsk eller fransk.

    Det er enkelt å løse dette ved å legge til en lang attributt til HTML-elementet:

    “No” forteller en skjermleser (eller oversettelsesprogramvare) at denne siden er på engelsk. “Es” er spansk, “fr” er fransk, og så videre. For de fleste språk er språklappen ganske enkel å bestemme. W3C har en guide til Valg av språkkode.

    Hvis siden inneholder innhold på et annet språk enn det viktigste deklarerte, legger du til et språkattributt til et element som omgir innholdet. For eksempel på en side som er erklært å være engelsk:

    Hvis du vil chatte a matador, i noe kult cabana
    Og møtes senoritas etter poengsummen, Espana por favor

    10) Hjelp en besøkende med å komme seg rundt innholdet ditt

    Kort sagt: bruk HTML-landemerkeelementer for å hjelpe hjelpende teknologibrukere med å forstå og navigere i innholdet ditt.

    Når en seende besøkende kommer til siden din, kan de enkelt skanne den visuelt for å forstå hvor navigasjonen er, og hvor hovedinnholdet begynner. En skjermleser bruker kan ikke gjøre dette. Imidlertid gir HTML5 oss noen nye tagger for å markere disse områdene, og hjelpemidler har snarveier som kan hoppe til (eller hoppe over) landemerker som Overskrift, bunntekst, navigasjon o.l.

    Her er en seks minutters video jeg laget med Léonie Watson, en nettutvikler og skjermleser bruker, om hvordan hun bruker skjermleseren sin til å undersøke disse semantikkene for å navigere på det personlige nettstedet mitt:

    • Pakk hovedinnholdet, det vil si ting som ikke er topptekst, primærnavigering eller bunntekst, i en
      element. I nesten alle tilfeller skal det bare være en
      per side. Alle nettlesere (IE9 +) lar deg style den, og hjelpemiddelteknologier vet hva du skal gjøre med det.
    • Pakk overskriften din (merkelogo, strapline, overskriften på siden) i a
      element.
    • Pakk inn bunnteksten (lovlige ting, kontaktdetaljer, varsel om copyright, osv.) I en
    • Merk opp din primære navigasjon ved å bruke
        innpakket i en element. Dette kan hekles inne i
        hvis det passer til den visuelle utformingen av siden.
      • Annonsering og ikke-essensielt innhold bør pakkes inn i et
      • Hvis du har mer enn ett produkt / video / nyhetsartikkel / blogginnlegg på en side, pakker du hvert av dem i et
        element.

      I sin kartlegging av brukere av skjermlesere, WebAIM fant at 26% av skjermleserbrukere ofte eller alltid bruker disse landemerkene når de navigerer på en side.

      I tillegg pakker du inn diskrete innholdsstykker i

      hjelper Apples WatchOS med å vise innhold optimalt. Se artikkelen min Den praktiske verdien av semantisk HTML for mer om dette.

      11) Bruk HTML riktig

      Kort sagt: forstå semantikken og standardatferden til HTML-elementer; bruk riktig element for innholdet ditt.

      Et vanlig tema i denne artikkelen har brukt riktige HTML-elementer. Bruker en merkelapp har en innebygd nettleseratferd som fokuserer det tilhørende inputfeltet; ved hjelp av

      er å foretrekke fremfor

      fordi det lar skjermleserbrukere hoppe rett til det viktige innholdet mens de er helt beskjedne for de som ikke bruker en skjermleser..

      Et annet eksempel er å bruke en

      Like this post? Please share to your friends:
Adblock
detector
map