Kort sagt, attributt ARIA:

• Gir eller forbedrer semantikk av ikke-semantiske eller andre semantiske elementer,

• Sikrer at dynamisk (live) innhold fremdeles er tilgjengelig.

• Gir rollen som beskriver typen definert widget (meny, treelement, glidebryter, fremdriftsmåler osv.).

• Gir rollen som beskriver strukturen til websiden (overskrifter, regioner og tabeller).

• Oppgir tilstanden til widgetene (merket av, har popup osv.).

• Gir egenskaper for dra-og-slipp som beskriver dragkilder og slippmål.

Hva er tilgjengelighet i nettdesign?

Når du designer et innhold, tenk på to ting: hvordan innholdet kan oppfattes og hvordan det kan brukes . La oss undersøke noen eksempler for å illustrere tilgjengelighet i nettdesign.

La oss si at du skal designe et egendefinert rullegardinelement. Her er ting du bør vurdere når du designer elementet:

• Merk forskjellige tilstander: aktivert, deaktivert, skrivebeskyttet.

• Merk elementet når det får fokus / svever.

• Merk hvert alternativelement når det blir fokus / svever.

• Forsikre deg om at innholdet fremdeles er lesbart når bare teksten er zoomet opp til 200% nivå.

• Forsikre deg om at det er nok kontrast mellom teksten og dens bakgrunn. Det hjelper personer med moderat nedsatt syn eller på enheter under ekstreme lysforhold, f.eks. Utsatt for direkte sollys eller på en skjerm med lav lysstyrke, å lese innholdet.

Et annet eksempel kan være å velge en farge for å beskrive en tilstand. Her er ting du bør vurdere når du designer en seksjon der brukeren vil være i stand til å plukke opp en farge:

• Det er mennesker som har problemer med å skille visse farger. Så grønt betyr ikke grønt for alle besøkende. For å fikse det, legg til en beskrivelse for hver farge som beskriver formålet.

• Merk hvert element når det får fokus / svever.

• Forsikre deg om at det er nok plass mellom elementene slik at hvert element enkelt kan aktiveres, f.eks. På enheter med mindre visningsport.

3. Testing av tilgjengelighet: Hvor skal jeg begynne?

Det er ingen en vei for å sjekke og være sikker på at nettinnhold er fullt tilgjengelig. Flere teknikker må brukes for å verifisere og fikse tilgjengelighetsproblemene. Du kan starte med definere problemer , løsninger , og prioriteringer .

Definere problemer

Mens du arbeider med tilgjengelighetsproblemer, må du alltid prøve å lage en billett per problem med en klar tittel. Dette skal forenkle forståelsen av problemet og bidra til å definere en prioritering.

Dårlig eksempel: Brukeren kan ikke bruke tastaturet på siden.

Godt eksempel: Kan ikke bruke tastaturnavigering i hovedmenyen.

Det dårlige eksemplet fører til en sak som vil være ganske vanskelig å avslutte på kort tid. Diskusjoner om flere emner kan også starte i kommentarfeltet, da billettittelen er for generisk.

Det gode eksemplet peker nøyaktig på problemet og fokuserer bare på en ting: tastaturnavigering i hovedmenyen.

Prioriter problemer med nettilgjengelighet

Prioriteringer er viktige fordi de definerer hvilke problemer som må løses først. For eksempel er WCAG delt på tre konformitetsnivåer : A, AA, AAA, som betyr at du bør starte fra et minimumsnivå A, men det betyr ikke automatisk at AA- og AAA-nivåene bare er 'fine å ha.' Alle nivåene er viktige, og det er viktig å ikke prioritere forutsatt at nivå A alene er tilstrekkelig.

WCAG-nivåer (eller andre retningslinjer) kan imidlertid være ganske vanskelig å forstå noen ganger, og for å forenkle det litt, kan du også vurdere følgende prioritetsdefinisjoner:

• Kritisk - Problemer som hindrer brukere i å bruke et program. Ingen løsninger tilgjengelig.

• Major - Problemer som gjør bruken av et program vanskelig og / eller desorienterende, men som ikke blokkerer brukerens mulighet til å fullføre operasjonen.

• Liten - Problemer som er irriterende, men som ikke hemmer bruken, eller forbedringer som kan gjøres i applikasjonen.

• Info - Overholder ikke beste praksis. Generelle anbefalinger for forbedringer.

Løsninger

Ingen av retningslinjene - som jeg mener WCAG , Seksjon 508 eller DET ER — Vil gi deg en rett løsning når det gjelder teknisk kode for hvordan et spesifisert problem skal løses. De definerer bare forventet atferd. WCAG har imidlertid i tillegg definert testprosedyrer som skal bidra til å forstå hvordan du kan gjengi problemet, og det finnes en automatisert WCAG Monitoring-fellesskapsgruppe, et W3C-fellesskap med fokus på å utvikle pålitelig regler for testing av nettilgjengelighet, både automatiserte og halvautomatiske.

Et eksempel for WCAG teknikk G4 ('Tillater at innholdet pauses og startes på nytt fra der det ble satt på pause'):

Test prosedyre

På en side med innhold som flytter eller blar,

1. Bruk mekanismen som er gitt på websiden eller av brukeragenten for å sette innholdet på bevegelse eller rulling på pause.

2. Kontroller at flyttingen eller rullingen har stoppet og ikke starter på nytt av seg selv.
3. Bruk mekanismen som følger med for å starte det bevegelige innholdet på nytt.
4. Kontroller at bevegelsen eller rullingen har gjenopptatt fra punktet der den ble stoppet.

forventede resultater

Nr. 2 og nr. 4 er sanne.

Som vi ser er det ingen tekniske løsninger, men definert forventet atferd. Hvordan webutviklere implementere det er opp til dem.

Retningslinjer for internetttilgang og W3C-standarder

Følgende grunnleggende nettstandarder bør være ditt utgangspunkt:

• Den vanligste er Retningslinjer for tilgjengelighet på nettinnhold kjent som WCAG. WCAG 2.0 er “En stabil, refererbar teknisk standard. Den har 12 retningslinjer som er organisert under 4 prinsipper: oppfattelig, brukbar, forståelig og robust . For hver retningslinje er det testbare suksesskriterier, som er på tre nivåer: A, AA og AAA . '

• Teknikker for WCAG 2.0 er en omfattende guide for forfattere av webinnhold.

• W3C Media Tilgjengelighet Brukerkrav - Dette dokumentet presenterer tilgjengelighetskravene brukere med funksjonshemninger har med hensyn til lyd og video på nettet.

• Tjueførste århundre kommunikasjons- og videotilgjengelighetslov - CVAA er delt inn i to brede titler eller seksjoner. Tittel I adresserer kommunikasjonstilgang for å gjøre produkter og tjenester ved bruk av bredbånd fullt tilgjengelig for mennesker med funksjonshemninger. Tittel II i tilgjengelighetsloven bryter ny vei for å gjøre det lettere for mennesker med funksjonshemninger å se videoprogrammering på TV og internett.

• Seksjon 508 - tilgjengelighetskrav for informasjons- og kommunikasjonsteknologi (IKT) som gjelder alle føderale byråer når de utvikler, anskaffer, vedlikeholder eller bruker elektronikk og informasjonsteknologi.

• Nettsteds tilgjengelighet under tittel II i Americans with Disabilities Act (ADA) - Der lærer du hvordan ikke-diskrimineringskravene i tittel II i ADA gjelder for statlige og lokale myndigheters nettsteder.

Testing av nettilgjengelighet: Hvordan vet jeg om innholdet mitt er tilgjengelig eller ikke?

Her er grunnleggende, grunnleggende sjekkpunkter som skal hjelpe deg med å gjøre nettinnholdet ditt mer tilgjengelig fra trinn 1:

• Valider HTML. Forsikre deg om at HTML-strukturen ikke har feil, da hjelpeteknologiene kan ha problemer med å tolke sideinnholdet.

• Test med tastatur alene. Forsikre deg om at alle handlingsbare elementer er tilgjengelige med bare tastatur. Du må også kunne utføre alle handlinger ved hjelp av et tastatur, for eksempel ved å sende inn et skjema.

• Test med verktøy og validatorer for tilgjengelighetsprøving. Bruk verktøy som skanner og verifiserer mulige tilgjengelighetsfeil.

• Dynamisk innhold. Gi beskjed til brukere av skjermleser om dynamiske endringer, f.eks. når søkeresultatene er endret.

• Ikke stol på farger for å beskrive betydningen. Bruk farge sammen med beskrivelsen, f.eks. [Gul boks] advarsel.

• Ikke fjern omrisset på fokus. Dette er en ofte fjernet funksjon ved bruk av CSS-egenskapen outline: 0; Ikke gjør det, siden brukerne av tastaturet mister retningen på siden. Du kan vurdere å fjerne fokusoversikten for brukere som ikke er tastaturer, men alltid gi en fokusoversikt for tastaturbrukere.

• Feilmeldinger. Fortell alltid brukeren hvordan man kan rette en feil. Ikke bare oppgi at dataene er ugyldige.

• Tabordrekkefølge. Sørg for at fanebasert navigering følger konvensjonene etablert i det grafiske brukergrensesnittet. I det minste bør den følge leseretningen til applikasjonens standardspråk. På engelsk, for eksempel, er lesrekkefølgen topp til bunn, fra venstre til høyre; på arabisk er det topp til bunn, høyre mot venstre.

• Zoom. Forsikre deg om at sideinnholdet fremdeles er lesbart mens du zoomer tekst opp til 200%.

• Slå av bilder. Er du fortsatt i stand til å bruke siden på en behagelig måte? Finnes det alternative tekster for alle bilder?

• Skjermleser. Test for å se om du kan lese og navigere gjennom innholdet ved hjelp av minst en skjermleser, for eksempel VoiceOver, Windows Narrator eller NVDA.

• Modus med høy kontrast. Sjekk om innholdet fremdeles er lesbart når du bytter til høykontrastmodus.

• Skriftstørrelse. Forsikre deg om at skriftstørrelsen på siden ikke har størrelse mindre enn 10 px.

4. Vanlige feil i nettilgjengelighet

Den vanligste feilen er unnlater å identifisere tilgjengelighetskrav før utvikling . Dessverre vil jo senere tilgjengelighet være en del av utviklingen, jo vanskeligere blir det å implementere løsninger.

Her er en liste med noen av de vanligste feilene utviklere gjør når de implementerer tilgjengelighet:

• Ingen evne til å navigere gjennom innholdet ved hjelp av bare et tastatur .

• Misbruk av CSS-områdegenskapen. I de fleste tilfeller outline: 0; brukes, noe som betyr at omrisset rundt hvert enkelt handlingselement ikke lenger er synlig. Ikke bruk outline: 0; eller outline: 0 !important; . Brukeren mister muligheten til å se det nåværende fokuserte elementet mens han navigerer gjennom innholdet, med mindre det er noe annet alternativ til det, for eksempel ved å bruke border CSS-eiendom.

• Mister fokus fra det nåværende elementet, f.eks. på grunn av DOM-manipulasjoner eller bruk av blur() metode. Dette skjer ofte for applikasjoner på en side.

• Ingen varsler for brukere av skjermleseren at noe er endret, for eksempel, innhold har blitt lastet ned ved hjelp av XMLHttpRequest API og nye endringer i brukergrensesnittet har blitt gjengitt, men brukeren har ikke blitt varslet. Dette skjer ofte med applikasjoner på en side.

• Utilgjengelig datovelger. I mange tilfeller brukes utilgjengelige datovelgere. Brukerne kan ikke navigere gjennom kalenderalternativene ved hjelp av tastaturet.

• Bruke utvidelser som hevder å fikser tilgjengelighetsproblemer automatisk . Bruk dem nøye og sjekk resultatene. Misbruk av dem kan skape flere problemer enn løsninger.

• Legger til elementet tabindex attributt med et indeksnummer på mer enn 0. Formålet med å bruke tabindex med en indeks på mer enn 0 er for det meste å 'korrigere' navigasjonsstien. Vurder imidlertid å endre HTML-strukturen for å få den naturlige navigasjonsveien. Manipulere den med tabindex kan føre til vedlikeholdsproblemer og en uforutsigbar navigasjonssti.

• Feil overskriftshierarki. Dessverre er det fortsatt ganske ofte sett, men topphierarkiet er ikke riktig bygget, f.eks.

  ,

  Og

  . Brukerne av skjermleseren bruker overskrifter for å navigere gjennom seksjonene, og feil struktur er forvirrende, da det er vanskelig å forstå sammenhengen.

• Mangler støtte med høy kontrast. Det er folk som bruker programvaren i høy kontrastmodus. Forsikre deg om at innholdet ditt fremdeles er synlig.

• Bruker en utilgjengelig CAPTCHA-løsning. Dessverre er alle CAPTCHA-er kjent for meg enten utilgjengelige eller veldig vanskelige å bruke.

• For mange og / eller ikke-pausbare animasjoner. Autospill av videoer, annonser eller bildekaruseller er veldig distraherende.

• Store biter av tekst. Tekst som er kondensert i en veldig stor, enkelt blokk, uten mellomrom, komma eller prikk. Veldig vanskelig å lese. Å dele inn i mindre biter, flere avsnitt og underoverskrifter hjelper deg med å organisere tekstinnholdet bedre.

• Zoomproblemer. Forsikre deg om at innholdet fremdeles er lesbart og navigerbart når du zoomer opp til 200%.

• Stole på farger. Svært ofte er tilstanden til et element bare markert med en farge, f.eks. Er en advarseltilstand bare merket med en gul kule; denne fargen oppfattes ikke på samme måte for fargeblinde mennesker.

• Små mål som kan klikkes / tappes. De klikkbare / tappbare områdene er ofte for små. Gjør det større lar brukerne aktivere dem lettere.

Men hvordan kan jeg forbedre nettilgjengeligheten?

Å definere problemene er en ting. Å fikse det er ganske annet og veldig ofte ikke så lett som det ser ut. Det er fordi API-implementeringer for tilgjengelighet ikke er konsistente, og noen ganger må vi finne løsninger eller til og med akseptere det faktum at noe ikke fungerer i det hele tatt når vi prøver å løse problemet.

Når det gjelder verktøy, er det ikke noe enkelt verktøy som kan sjekke alle mulige kombinasjoner, men som en god start, bør disse verktøyene hjelpe:

• Valideringstjeneste for W3C - Bare for å være sikker på at HTML-innholdet ikke har noen feil. Hvis HTML-strukturen har feil, er utdataene uforutsigbare og kan ikke behandles ordentlig, spesielt av forskjellige hjelpemidler .

• https://www.w3.org/WAI/ER/tools/ - En liste over programmer eller nettbaserte tjenester som hjelper deg med å avgjøre om nettinnhold oppfyller retningslinjene for tilgjengelighet.

• Og verktøyet mitt, ASLint https://www.aslint.org/ , hjelper deg med å finne tilgjengelighetsproblemer.

Husk alltid at ingen tilgjengelighetsverktøy kan erstatte manuell testing , da ikke alle scenarier kan være fullstendig eller i det hele tatt automatiserte, for eksempel å kontrollere luminanskontrastforholdet på elementer med position: fixed;.

Fokuser på problemer som blokkerer bruken av applikasjonen din, for eksempel kan brukeren ikke navigere gjennom menyen ved hjelp av tastaturet.

Hvorfor det er viktig å gjøre innhold tilgjengelig

Alle ønsker å spre innholdet så bredt som mulig. Tilgjengelighet hjelper i dette området, på mange nivåer, fra å nå et større publikum til å forbedre brukeropplevelsen for alle brukere. Dessuten er tilgjengelighet ikke bare for det du tradisjonelt kan tenke på som mennesker med nedsatt funksjonsevne. Enten det er en person som eldes og går gjennom de medfølgende fysiske endringene, noen som jogger på en solskinnsdag som trenger automatisk kontrastjustering på telefonen, eller en forelder med hender fulle av handlekurver som vil sende en tekstmelding med stemmen, tilgjengelig teknologi er teknologi alle brukere kan bruke fra tid til annen.

Som en ekstra bonus er den positive effekten at tilgjengelig innhold som oppfyller WCAG 2.0-standardene er lettere å gjennomgå og forstå av søkemotorer, og som kan ha en betydelig innvirkning på hvordan et nettsted rangeres. Dermed kan tilgjengelig design føre til ekstra trafikk til nettstedet.

Til slutt, her er noen statistikker du må vurdere:

• Mer enn en milliard mennesker over hele verden opplever noen form for funksjonshemning.

• Aldring av befolkningen . Mellom 2015 og 2030 forventes antall eldre personer - de som er 60 år eller eldre - i verden å vokse med 56 prosent, fra 901 millioner til mer enn 1,4 milliarder.

• Universell design er nøkkelen. Universell design refererer til et bredt spekter av ideer og praksis for å produsere tjenester, produkter og miljøer som iboende er tilgjengelige og brukbare av mennesker med alle evner.

• Typer av funksjonshemninger: Det er fem brede kategorier av funksjonshemninger, inkludert visuell, mobilitet, tale, kognisjon og hørsel.

Vi trenger alle tjenester av høy kvalitet. La oss også levere dem .

Forstå det grunnleggende

Hva er tilgjengelighet i webdesign?

Nettilgjengelighet er praksis for å fjerne ulike hindringer for tilgang og brukerinteraksjon med innhold på nettet. Hensikten er å sikre nettilgang for mennesker med funksjonshemninger, så vel som alle andre brukere som kan trenge tilgang til innhold ukonvensjonelt.

Hva er WCAG-samsvar?

Enkelt sagt, å være WCAG-kompatibel betyr at du implementerer riktig retningslinjer for tilgjengelighet på nettinnhold (WCAG). Ta en titt på WCAG 2.0 hurtigreferanse for mer informasjon om hvordan du oppfyller ulike kriterier.

Hva er WCAG 2.0-standarden?

WCAG 2.0 står for retningslinjer for tilgjengelighet for webinnhold. Det er en teknisk standard som består av 12 retningslinjer, som følger fire grunnleggende prinsipper. Hver retningslinje er testet og vurdert for samsvar.