window.pipedriveLeadboosterConfig = { base: 'leadbooster-chat.pipedrive.com', companyId: 11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', version: 2, } ;(funktion () { var w = vindue if (w.LeadBooster) { console.warn('LeadBooster findes allerede') } else { w.LeadBooster = { q: [], on: function (n, h) { this.q.push({ t: 'o', n: n, h: h }) }, trigger: function (n) { this.q.push({ t: 't', n: n }) }, } } })() 4 almindelige problemer med webtilgængelighed, du skal kende - The Codest
Codest
  • Om os
  • Serviceydelser
    • Udvikling af software
      • Frontend-udvikling
      • Backend-udvikling
    • Staff Augmentation
      • Frontend-udviklere
      • Backend-udviklere
      • Dataingeniører
      • Cloud-ingeniører
      • QA-ingeniører
      • Andet
    • Det rådgivende
      • Revision og rådgivning
  • Industrier
    • Fintech og bankvirksomhed
    • E-commerce
    • Adtech
    • Sundhedsteknologi
    • Produktion
    • Logistik
    • Biler
    • IOT
  • Værdi for
    • ADMINISTRERENDE DIREKTØR
    • CTO
    • Leder af levering
  • Vores team
  • Casestudier
  • Ved hvordan
    • Blog
    • Møder
    • Webinarer
    • Ressourcer
Karriere Tag kontakt til os
  • Om os
  • Serviceydelser
    • Udvikling af software
      • Frontend-udvikling
      • Backend-udvikling
    • Staff Augmentation
      • Frontend-udviklere
      • Backend-udviklere
      • Dataingeniører
      • Cloud-ingeniører
      • QA-ingeniører
      • Andet
    • Det rådgivende
      • Revision og rådgivning
  • Værdi for
    • ADMINISTRERENDE DIREKTØR
    • CTO
    • Leder af levering
  • Vores team
  • Casestudier
  • Ved hvordan
    • Blog
    • Møder
    • Webinarer
    • Ressourcer
Karriere Tag kontakt til os
Pil tilbage GÅ TILBAGE
2022-11-15
Udvikling af software

4 almindelige problemer med webtilgængelighed, du skal kende

Codest

Reda Salmi

React Udvikler

Nettet bruges af millioner af forskellige mennesker hver dag, og et af vores hovedmål som udviklere er at gøre nettet tilgængeligt for alle. Denne artikel introducerer nogle almindelige problemer med webtilgængelighed og måder at løse dem på.

Problem med kontrastforhold

Det mest almindelige tilgængelighedsproblem, jeg har set gennem årene, er Problem med kontrast og farvetilgængelighedEt dårligt kontrastforhold vil gøre det svært at se indholdet på din side, og det vil være meget skadeligt for dine brugere, også dem med synshandicap.

Kontrast er et mål for forskellen i opfattet "luminans" eller lysstyrke mellem to farver, for eksempel er det forskellen mellem baggrundsfarven og forgrundsfarven på din sides indhold. Lad os se på denne navbar.

navigationsbjælke med<em>grønne</em> titler

Lad os sige, at din kunde virkelig kan lide den grønlige farve og synes, den er fantastisk, men der er et problem med kontrasten. Vi har en #FFFFFF baggrund med en #83A94C tekstfarve, hvilket resulterer i et kontrastforhold på 2,71:1, hvilket er langt under minimumskravet. 4.5:1 nødvendigt. For at opdage dette problem har vi flere løsninger:

  1. Brug et online-kontrasttjek som f.eks. Webaim-kontrastkontrolsom beregner kontrastforholdet og giver dig en Passér eller Mislykkes klasse.
  2. Brug en af de mange udvidelser til kontrastkontrol i browseren, f.eks: WCAG Kontrol af farvekontrast.
  3. Prøv browserens integrerede kontrastkontrol. For at bruge den i Google Chrome skal du åbne udviklingsværktøjerne, inspicere det ønskede element (f.eks. startlinket i vores navbar), gå til CSS-farveegenskaben og klikke på farverektanglet for at åbne farvevælgeren, nederst vil du blive præsenteret for en kontrastforholdsværdi, udvid den for at få flere detaljer. Processen er nøjagtig den samme for Firefox, der er bare en lille forskel i forholdet, som vises nederst til venstre i farvevælgeren.
sort<em>baggrund</em>med<em>blå</em>kode

For at få flere detaljer om kontrast tjek dette Artikel om kontrast- og farvetilgængelighed.

Problem med link-tekst

Links er en stor del af internettet i dag, så det er meget vigtigt at gøre dem tilgængelige. Et link skal give mening og informere brugeren om dets kontekst, så et uinformativt link med tekst som læs mere, klik her, tjek detaljer er ikke særlig nyttigt, så i stedet for at tilføje "tjek detaljer" til produkt detaljer, for eksempel er det bedre og mere informativt at bruge produktnavnet som "The Mandalorian Helmet". Ord som klik her eller mere om kan udelades, fordi et link som standard er klikbart, og noget som "mere om dagens nyheder" kan forkortes til "dagens nyheder". Der er ingen særlig regel eller grænse for linklængden. Linket skal være læsbart og lang nok til at give en god beskrivelse af dens formål.

Billeder som links er et meget brugt mønster, så det skal følge de samme regler, som vi har talt om ovenfor. Billedets alt-attribut vil spille rollen som linktekst og blive annonceret af skærmlæsere. Der er flere scenarier for behandling af billeder som links: Hvis billedet er det eneste indhold i linket, skal det have en alt-attribut, og hvis linket indeholder både tekst og billede, kan vi udelade alt-attributten - her er nogle eksempler:


<a href="/da/notifications/">
  <img src="/img/notification.png" alt="Meddelelser">
</a>

Se nogle links her for at læse om tilgængelighed til links:Linktekst og udseende, Funktionelle billeder.

Formularinput mangler en etiket

input<em>labels</em>med<em>blå</em>knap

Vi har alle set disse formularinput før uden etiket og kun en pladsholder til at beskrive formålet med inputtet. En første bemærkning er, at så snart brugeren har udfyldt alle input, og pladsholderne ikke længere er synlige, vil vi ikke have nogen visuel kontekst om inputtenes formål, men lad os fokusere på tilgængeligheden her.

Tilknytning af en mærke til et input giver os to store fordele: En skærmlæser vil læse etiketten op, når brugeren har fokus på formularinputtet, og når der klikkes på en etiket, eller der røres ved den, flytter browseren fokus til det tilhørende input. En nem løsning på den slags situationer er bare at tilføje labels på følgende måde:

    Fornavn

    
  

    Efternavn

    
  

    E-mail

    
  

    Send ind
  

```

Det var det, alle inputs har deres tilhørende labels, hvilket gør dem tilgængelige for alle. Vi kan endda fjerne pladsholderne for at undgå at duplikere formålet med input, men vi ved alle, at scenarier i den virkelige verden ikke er så nemme at håndtere, du har lige modtaget et design, der har disse formularinput uden labels, og kunden ønsker ikke at ændre den del. Den første løsning, man kommer i tanke om, er at anvende en display: ingen; eller synlighed: skjult; til vores etiketter, vil det skjule dem, men de er der stadig, ikke? Disse egenskaber skjuler ikke kun elementer på skærmen, men også for brugere af skærmlæsere, så det vil ikke løse vores problem.

Vi kan bruge Clipsmønster til at løse dette. På den måde vil vi skjule indholdet visuelt, men alligevel give indholdet til skærmlæsere. Vi opretter følgende CSS Kun sr klasse og anvende den på alle vores etiketter:

 .sr-only:not(:focus):not(:active) {
   clip: rect(0 0 0 0);
   clip-path: inset(50%);
   højde: 1px;
   overløb: skjult;
   position: absolut;
   white-space: nowrap;
   width: 1px;
 }

Det vil skjule vores etiketter, gøre dem tilgængelige for skærmlæsere og matche vores design. Den :not(:focus):not(:active) pseudoklasse forhindrer fokuserbare elementer som f.eks. a, knap, input fra at blive skjult, når man modtager fokus.

Ingen fokusindikator

Engang gjorde jeg det i mit globale CSS-stilark:

* {
outline: none; /* forfærdelig fejl */
}

Omkring 2020 bemærkede jeg, at der dukkede sorte kanter op på Google Chrome-formularinput, når de var fokuserede, eller på knapperne, når man tabbede ind - det var virkelig underligt, da jeg ikke forstod det på det tidspunkt, men efter nogle undersøgelser har jeg fundet ud af, at det er på grund af CSS-egenskaben outline, så det løste det 'problem' for mig at fjerne.

På det tidspunkt havde jeg ingen idé om, hvad der var den rigtige måde at gøre det på. Efter at have undersøgt hvorfor og hvordan med den nye standard fandt jeg ud af, at outline er en elementfokusindikator, og hvis den fjernes, skal der være en tydelig fokusstyling, så det, jeg gjorde, betragtes som en dårlig praksis. Du kan tilpasse fokusindikatorer, som du vil, men at fjerne dem helt fra hjemmesiden er et stort tilgængelighedsproblem. Det er f.eks. ret nemt at tilpasse et elements fokusstyling:

 a:focus {
   outline: 4px solid #ee7834;
   outline-offset: 4px;
 }

Værktøjer til tilgængelighed

Det kan være et stort arbejde at tjekke alle de emner, vi har talt om, især når man ved, at der er mange flere ting, der skal dækkes om tilgængelighed, så for at hjælpe os med at håndtere tilgængelighed har vi 2 gode browserudvidelser.

WAVE evalueringsværktøj er en række evalueringsværktøjer, der hjælper os med at gøre vores webindhold mere tilgængeligt. Den er tilgængelig i både Google Chrome og Firefox.

Lad os prøve det på en lille webside, der indeholder en navigationslinje og et input, der mangler en etiket, og se, hvad den returnerer, når vi har installeret udvidelsen, skal vi bare klikke på udvidelsesikonet for at bruge den.

hvidt<em>vindue</em> med<em>grå</em> sektioner

Fanen Summary viser 1 fejl (formularelementet mangler en label), 2 kontrastfejl og 1 advarsel (manglende overskriftsstruktur), og som du kan se, er resultatet meget klart og detaljeret. Fanen Detaljer viser en liste over alle fejl, advarsler og funktioner. Vi kan også interagere direkte på siden ved at klikke på de røde rektangler for at tjekke fejlbeskrivelsen og -typen.

Axe DevTools er et kraftfuldt og præcist tilgængelighedsværktøjssæt. Det er tilgængeligt i både Google Chrome og Firefox. Når vi har installeret udvidelsen, skal vi åbne browserens udviklingsværktøjer og gå til fanen axe DevTools og klikke på Scan alle mine sider.

DevTools<em>vindue</em>med<em>sorte</em>grå_sektioner

Du kan se, at Axe DevTools har rapporteret de samme problemer med WAVE Evaluation Tool, som er kontrastproblemer, formularelementer, der mangler en etiket, og manglende overskriftselementer, og det gav os endda nogle bedste fremgangsmåder at følge.

En anden måde at teste tilgængeligheden på er at bruge en skærmlæser og teste dit website med den. Der findes mange skærmlæsere, for blot at nævne nogle få:

  • NVDA
  • VoiceOver er tilgængelig på macOs-enheder.
  • Spækhugger er en gratis og open source-skærmlæser til Linux.

Sammenfatning

I denne artikel har vi set på nogle almindelige problemer med webtilgængelighed, måder at løse dem på og nogle gode værktøjer til at teste for webtilgængelighed. Der er stadig meget mere at lære om tilgængelighed for elementer som dialogbokse, harmonikaer og karruseller, men som du har set i denne artikel, er der masser af dokumentation og værktøjer, der kan hjælpe dig med at håndtere tilgængelighed.

Nogle vigtige punkter at huske:

  • Tjek altid kontrastforholdet.
  • Giv altid informativt indhold til links.
  • Et formularelement skal have en label tilknyttet.
  • Der skal være tydelig fokusstyling.
karriere på codest

Relaterede artikler

E-commerce

Dilemmaer i forbindelse med cybersikkerhed: Læk af data

Førjulsræset er i fuld gang. I jagten på gaver til deres kære er folk i stigende grad villige til at "storme" onlinebutikker

Codest
Jakub Jakubowicz CTO og medstifter
Udvikling af software

Javascript-værktøjer i aktion

Opdag nogle værktøjer til at hente JavaScript, så du kan forbedre dit programmeringsspil. Få mere at vide om ESLint, Prettier og Husky!

Codest
Reda Salmi React Udvikler
Udvikling af software

9 fejl, du skal undgå, når du programmerer i Java

Hvilke fejl bør man undgå, når man programmerer i Java? I det følgende afsnit besvarer vi dette spørgsmål.

Codest
Rafal Sawicki Java-udvikler

Tilmeld dig vores vidensbase, og hold dig opdateret om ekspertisen fra it-sektoren.

    Om os

    The Codest - International softwareudviklingsvirksomhed med tech-hubs i Polen.

    Storbritannien - Hovedkvarter

    • Kontor 303B, 182-184 High Street North E6 2JA
      London, England

    Polen - Lokale teknologiske knudepunkter

    • Fabryczna Office Park, Aleja
      Pokoju 18, 31-564 Kraków
    • Hjerneambassaden, Konstruktorska
      11, 02-673 Warszawa, Polen

      Codest

    • Hjem
    • Om os
    • Serviceydelser
    • Casestudier
    • Ved hvordan
    • Karriere
    • Ordbog

      Serviceydelser

    • Det rådgivende
    • Udvikling af software
    • Backend-udvikling
    • Frontend-udvikling
    • Staff Augmentation
    • Backend-udviklere
    • Cloud-ingeniører
    • Dataingeniører
    • Andet
    • QA-ingeniører

      Ressourcer

    • Fakta og myter om at samarbejde med en ekstern softwareudviklingspartner
    • Fra USA til Europa: Hvorfor beslutter amerikanske startups sig for at flytte til Europa?
    • Sammenligning af Tech Offshore-udviklingsknudepunkter: Tech Offshore Europa (Polen), ASEAN (Filippinerne), Eurasien (Tyrkiet)
    • Hvad er de største udfordringer for CTO'er og CIO'er?
    • Codest
    • Codest
    • Codest
    • Privacy policy
    • Vilkår for brug af hjemmesiden

    Copyright © 2025 af The Codest. Alle rettigheder forbeholdes.

    da_DKDanish
    en_USEnglish de_DEGerman sv_SESwedish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian jaJapanese ko_KRKorean es_ESSpanish nl_NLDutch etEstonian elGreek da_DKDanish