Merge f53b89db55 into 4ccb645e24
Karsten Vestergaard
3 months ago
committed by
GitHub
commit
e5d0892ab4
@ -0,0 +1,203 @@
|
||||
# Introduktion til programmeringssprog og værktøjer i branchen
|
||||
|
||||
Denne lektion dækker det grundlæggende i programmeringssprog. De emner, der omtales her, gælder for de fleste moderne programmeringssprog i dag. I afsnittet 'Tools of the Trade' lærer du om nyttig software, der hjælper dig som udvikler.
|
||||
|
||||
|
||||
> Sketchnote by [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## Quiz før undervisning
|
||||
[Pre-lecture quiz](https://ashy-river-0debb7803.1.azurestaticapps.net/quiz/1)
|
||||
|
||||
## Introduktion
|
||||
|
||||
I denne lektion vil vi dække:
|
||||
|
||||
- Hvad er programmering?
|
||||
- Typer af programmeringssprog
|
||||
- Grundlæggende elementer i et program
|
||||
- Nyttig software og værktøj til den professionelle udvikler
|
||||
|
||||
> Du kan tage denne lektion på [Microsoft Learn] (https://docs.microsoft.com/learn/modules/web-development-101/introduction-programming/?WT.mc_id=academic-77807-sagibbon)!
|
||||
|
||||
## Hvad er programmering?
|
||||
|
||||
Programmering (også kendt som kodning) er processen med at skrive instruktioner til en enhed som f.eks. en computer eller en mobil enhed. Vi skriver disse instruktioner med et programmeringssprog, som derefter fortolkes af enheden. Disse sæt af instruktioner kan have forskellige navne, men *program*, *computerprogram*, *applikation (app)* og *eksekverbar (executable)* er nogle få populære navne.
|
||||
|
||||
Et *program* kan være alt, der er skrevet med kode; hjemmesider, spil og telefonapps er programmer. Selvom det er muligt at skabe et program uden at skrive kode, fortolkes den underliggende logik af enheden, og den logik blev sandsynligvis skrevet med kode. Et program, der *kører* eller *eksekverer* kode, udfører instruktioner. Den enhed, du læser denne lektion med, kører et program for at udskrive den til din skærm.
|
||||
|
||||
✅ Lav lidt research: Hvem anses for at have været verdens første computerprogrammør?
|
||||
|
||||
## Programmeringssprog
|
||||
|
||||
Programmeringssprog gør det muligt for udviklere at skrive instruktioner til en enhed. Enheder kan kun forstå binære tal (1'ere og 0'ere), og for *de fleste* udviklere er det ikke en særlig effektiv måde at kommunikere på. Programmeringssprog er midlet til kommunikation mellem mennesker og computere.
|
||||
|
||||
Programmeringssprog findes i forskellige formater og kan tjene forskellige formål. For eksempel bruges JavaScript primært til webapplikationer, mens Bash primært bruges til operativsystemer.
|
||||
|
||||
*Lavniveausprog* kræver typisk færre trin end *højniveausprog*, for at en enhed kan fortolke instruktioner. Men det, der gør højniveausprog populære, er deres læsbarhed og support. JavaScript betragtes som et højniveausprog.
|
||||
|
||||
Følgende kode illustrerer forskellen mellem et højniveausprog med JavaScript og et lavniveausprog med ARM-assemblerkode.
|
||||
|
||||
```javascript
|
||||
let number = 10
|
||||
let n1 = 0, n2 = 1, nextTerm;
|
||||
|
||||
for (let i = 1; i <= number; i++) {
|
||||
console.log(n1);
|
||||
nextTerm = n1 + n2;
|
||||
n1 = n2;
|
||||
n2 = nextTerm;
|
||||
}
|
||||
```
|
||||
|
||||
```c
|
||||
area ascen,code,readonly
|
||||
entry
|
||||
code32
|
||||
adr r0,thumb+1
|
||||
bx r0
|
||||
code16
|
||||
thumb
|
||||
mov r0,#00
|
||||
sub r0,r0,#01
|
||||
mov r1,#01
|
||||
mov r4,#10
|
||||
ldr r2,=0x40000000
|
||||
back add r0,r1
|
||||
str r0,[r2]
|
||||
add r2,#04
|
||||
mov r3,r0
|
||||
mov r0,r1
|
||||
mov r1,r3
|
||||
sub r4,#01
|
||||
cmp r4,#00
|
||||
bne back
|
||||
end
|
||||
```
|
||||
|
||||
Tro det eller ej, *de gør begge det samme*: udskriver en Fibonacci-sekvens op til 10.
|
||||
|
||||
✅ En Fibonacci-sekvens er [defineret](https://en.wikipedia.org/wiki/Fibonacci_number) som et sæt tal, hvor hvert tal er summen af de to foregående, startende fra 0 og 1. De første 10 tal, der følger Fibonacci-sekvensen, er 0, 1, 1, 2, 3, 5, 8, 13, 21 og 34.
|
||||
|
||||
## Elementer i et program
|
||||
|
||||
En enkelt instruktion i et program kaldes et *statement* og vil normalt have et tegn eller en linjeafstand, der markerer, hvor instruktionen slutter, eller *terminates*. Hvordan et program afsluttes, varierer fra sprog til sprog.
|
||||
|
||||
Udsagn i et program kan være afhængige af data fra en bruger eller andre steder for at udføre instruktioner. Data kan ændre, hvordan et program opfører sig, så programmeringssprog har en måde at gemme data midlertidigt på, så de kan bruges senere. Disse kaldes *variabler*. Variabler er udsagn, der instruerer en enhed i at gemme data i dens hukommelse. Variabler i programmer svarer til variabler i algebra, hvor de har et unikt navn, og deres værdi kan ændre sig over tid.
|
||||
|
||||
Der er en chance for, at nogle udsagn ikke vil blive udført af en enhed. Det er som regel bevidst, når det er skrevet af udvikleren, eller ved et uheld, når der opstår en uventet fejl. Denne form for kontrol over en applikation gør den mere robust og vedligeholdelig. Typisk sker disse ændringer i kontrollen, når visse betingelser er opfyldt. En almindelig sætning, der bruges i moderne programmering til at kontrollere, hvordan et program kører, er `if..else`-sætningen.
|
||||
|
||||
✅ Du vil lære mere om denne type udsagn i de efterfølgende lektioner.
|
||||
|
||||
## Fagets værktøjer
|
||||
|
||||
[](https://youtube.com/watch?v=69WJeXGBdxg "Tools of the Trade")
|
||||
|
||||
> 🎥 Klik på billedet ovenfor for at se en video om værktøjer
|
||||
|
||||
I dette afsnit vil du lære om noget software, som du måske vil finde meget nyttigt, når du starter din professionelle udviklingsrejse.
|
||||
|
||||
Et **udviklingsmiljø** er et unikt sæt af værktøjer og funktioner, som en udvikler ofte bruger, når han skriver software. Nogle af disse værktøjer er blevet tilpasset en udviklers specifikke behov og kan ændre sig over tid, hvis udvikleren ændrer prioriteter i arbejdet, personlige projekter, eller når de bruger et andet programmeringssprog. Udviklingsmiljøer er lige så unikke som de udviklere, der bruger dem.
|
||||
|
||||
### Editorer
|
||||
|
||||
Et af de mest afgørende værktøjer til softwareudvikling er editoren. Editorer er der, hvor du skriver din kode, og nogle gange der, hvor du kører din kode.
|
||||
|
||||
Udviklere er afhængige af editorer af et par andre grunde:
|
||||
|
||||
- *Debugging* hjælper med at afdække fejl og mangler ved at gennemgå koden linje for linje. Nogle editorer har debugging-funktioner; de kan tilpasses og tilføjes til specifikke programmeringssprog.
|
||||
- *Syntaksfremhævning* tilføjer farver og tekstformatering til koden, hvilket gør den lettere at læse. De fleste editorer tillader tilpasset syntaksfremhævning.
|
||||
- *Udvidelser og integrationer* er specialiserede værktøjer til udviklere, af udviklere. Disse værktøjer er ikke indbygget i basiseditoren. For eksempel dokumenterer mange udviklere deres kode for at forklare, hvordan den fungerer. De installerer måske en stavekontroludvidelse for at hjælpe med at finde stavefejl i dokumentationen. De fleste udvidelser er beregnet til brug i en bestemt editor, og de fleste editorer kommer med en måde at søge efter tilgængelige udvidelser.
|
||||
- *Tilpasning* gør det muligt for udviklere at skabe et unikt udviklingsmiljø, der passer til deres behov. De fleste editorer kan tilpasses ekstremt meget og kan også give udviklere mulighed for at oprette tilpassede udvidelser.
|
||||
|
||||
#### Populære editorer og udvidelser til webudvikling
|
||||
|
||||
- [Visual Studio Code](https://code.visualstudio.com/?WT.mc_id=academic-77807-sagibbon)
|
||||
- [Code Spell Checker](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker)
|
||||
- [Live Share](https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare)
|
||||
- [Prettier - Code formatter](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode)
|
||||
- [Atom](https://atom.io/)
|
||||
- [spell-check](https://atom.io/packages/spell-check)
|
||||
- [teletype](https://atom.io/packages/teletype)
|
||||
- [atom-beautify](https://atom.io/packages/atom-beautify)
|
||||
|
||||
- [www.sublimetext](https://www.sublimetext.com/)
|
||||
- [emmet](https://emmet.io/)
|
||||
- [SublimeLinter](http://www.sublimelinter.com/en/stable/)
|
||||
|
||||
### Browsere
|
||||
|
||||
Et andet vigtigt værktøj er browseren. Webudviklere er afhængige af browseren for at se, hvordan deres kode kører på nettet. Den bruges også til at vise de visuelle elementer på en webside, der er skrevet i editoren, som HTML.
|
||||
|
||||
Mange browsere leveres med *udviklerværktøjer* (DevTools), der indeholder et sæt nyttige funktioner og oplysninger, der hjælper udviklere med at indsamle og registrere vigtige oplysninger om deres applikation. For eksempel: Hvis en webside har fejl, er det nogle gange nyttigt at vide, hvornår de opstod. DevTools i en browser kan konfigureres til at indfange disse oplysninger.
|
||||
|
||||
#### Populære browsere og DevTools
|
||||
|
||||
- [Edge](https://docs.microsoft.com/microsoft-edge/devtools-guide-chromium/?WT.mc_id=academic-77807-sagibbon)
|
||||
- [Chrome](https://developers.google.com/web/tools/chrome-devtools/)
|
||||
- [Firefox](https://developer.mozilla.org/docs/Tools)
|
||||
|
||||
### Kommandolinjeværktøjer (Command Line Tools)
|
||||
|
||||
Nogle udviklere foretrækker en mindre grafisk visning til deres daglige opgaver og er afhængige af kommandolinjen for at opnå dette. At skrive kode kræver en betydelig mængde indtastning, og nogle udviklere foretrækker ikke at forstyrre deres flow på tastaturet. De vil bruge tastaturgenveje til at skifte mellem skrivebordsvinduer, arbejde på forskellige filer og bruge værktøjer. De fleste opgaver kan udføres med musen, men en fordel ved at bruge kommandolinjen er, at meget kan gøres med kommandolinjeværktøjer, uden at man behøver at skifte mellem mus og tastatur. En anden fordel ved kommandolinjen er, at de kan konfigureres, og du kan gemme en brugerdefineret konfiguration, ændre den senere og importere den til andre udviklingsmaskiner. Fordi udviklingsmiljøer er så unikke for hver enkelt udvikler, vil nogle undgå at bruge kommandolinjen, andre vil være helt afhængige af den, og nogle foretrækker en blanding af de to.
|
||||
|
||||
### Populære indstillinger for kommandolinjen
|
||||
|
||||
Indstillingerne for kommandolinjen vil variere afhængigt af det operativsystem, du bruger.
|
||||
|
||||
*💻 = er forudinstalleret på operativsystemet.*
|
||||
|
||||
#### Windows
|
||||
|
||||
- [Powershell](https://docs.microsoft.com/powershell/scripting/overview?view=powershell-7/?WT.mc_id=academic-77807-sagibbon) 💻
|
||||
- [Command Line](https://docs.microsoft.com/windows-server/administration/windows-commands/windows-commands/?WT.mc_id=academic-77807-sagibbon) (also known as CMD) 💻
|
||||
- [Windows Terminal](https://docs.microsoft.com/windows/terminal/?WT.mc_id=academic-77807-sagibbon)
|
||||
- [mintty](https://mintty.github.io/)
|
||||
|
||||
#### MacOS
|
||||
|
||||
- [Terminal](https://support.apple.com/guide/terminal/open-or-quit-terminal-apd5265185d-f365-44cb-8b09-71a064a42125/mac) 💻
|
||||
- [iTerm](https://iterm2.com/)
|
||||
- [Powershell](https://docs.microsoft.com/powershell/scripting/install/installing-powershell-core-on-macos?view=powershell-7/?WT.mc_id=academic-77807-sagibbon)
|
||||
|
||||
#### Linux
|
||||
|
||||
- [Bash](https://www.gnu.org/software/bash/manual/html_node/index.html) 💻
|
||||
- [KDE Konsole](https://docs.kde.org/trunk5/en/konsole/konsole/index.html)
|
||||
- [Powershell](https://docs.microsoft.com/powershell/scripting/install/installing-powershell-core-on-linux?view=powershell-7/?WT.mc_id=academic-77807-sagibbon)
|
||||
|
||||
#### Populære kommandolinjeværktøjer
|
||||
|
||||
- [Git](https://git-scm.com/) (💻 på de fleste operativsystemer)
|
||||
- [NPM](https://www.npmjs.com/)
|
||||
- [Yarn](https://classic.yarnpkg.com/en/docs/cli/)
|
||||
|
||||
### Dokumentation
|
||||
|
||||
Når en udvikler vil lære noget nyt, vil han eller hun højst sandsynligt se på dokumentationen for at lære, hvordan man bruger det. Udviklere er ofte afhængige af dokumentation til at guide dem gennem, hvordan man bruger værktøjer og sprog korrekt, og også til at få dybere viden om, hvordan det fungerer.
|
||||
|
||||
#### Populær dokumentation om webudvikling
|
||||
|
||||
- [Mozilla Developer Network (MDN)](https://developer.mozilla.org/docs/Web), fra Mozilla, udgiverne af browseren [Firefox](https://www.mozilla.org/firefox/)
|
||||
- [Frontend Masters](https://frontendmasters.com/learn/)
|
||||
- [Web.dev](https://web.dev), fra Google, udgiverne af [Chrome](https://www.google.com/chrome/)
|
||||
- [Microsoft's own developer docs](https://docs.microsoft.com/microsoft-edge/#microsoft-edge-for-developers), for [Microsoft Edge](https://www.microsoft.com/edge)
|
||||
- [W3 Schools](https://www.w3schools.com/where_to_start.asp)
|
||||
|
||||
✅ Lav noget research: Nu, hvor du kender det grundlæggende i en webudviklers miljø, kan du sammenligne og kontrastere det med en webdesigners miljø.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Udfordring
|
||||
|
||||
Sammenlign nogle programmeringssprog. Hvad er nogle af de unikke træk ved JavaScript vs. Java? Hvad med COBOL vs. Go?
|
||||
|
||||
## Quiz efter undervisning
|
||||
[Post-lecture quiz](https://ashy-river-0debb7803.1.azurestaticapps.net/quiz/2)
|
||||
|
||||
## Gennemgang og selvstudium
|
||||
|
||||
Læs lidt om de forskellige sprog, der er til rådighed for programmøren. Prøv at skrive en linje i ét sprog, og skriv den så om i to andre. Hvad har du lært?
|
||||
|
||||
## Opgave
|
||||
|
||||
[Læsning af dokumentation](assignment.md)
|
||||
@ -0,0 +1,333 @@
|
||||
# Introduktion til GitHub
|
||||
|
||||
Denne lektion dækker det grundlæggende i GitHub, en platform til at hoste og administrere ændringer i din kode.
|
||||
|
||||
|
||||
> Sketchnote by [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## Quiz før undervisning
|
||||
[Pre-lecture quiz](https://ashy-river-0debb7803.1.azurestaticapps.net/quiz/3)
|
||||
|
||||
## Introduktion
|
||||
|
||||
I denne lektion vil vi dække:
|
||||
|
||||
- sporing af det arbejde, du udfører på din maskine
|
||||
- at arbejde på projekter sammen med andre
|
||||
- hvordan man bidrager til open source-software
|
||||
|
||||
### Forudsætninger
|
||||
|
||||
Før du begynder, skal du tjekke, om Git er installeret. Skriv i terminalen:
|
||||
`git --version`
|
||||
|
||||
Hvis Git ikke er installeret, skal du [downloade Git] (https://git-scm.com/downloads). Opsæt derefter din lokale Git-profil i terminalen:
|
||||
* `git config --global user.name "dit-navn"`
|
||||
* `git config --global user.email "din-email"`
|
||||
|
||||
For at tjekke, om Git allerede er konfigureret, kan du skrive:
|
||||
`git config --list`
|
||||
|
||||
For at tjekke, om Git allerede er konfigureret, kan du skrive:
|
||||
`git config --list`
|
||||
|
||||
Du skal også bruge en GitHub-konto, en kodeeditor (som Visual Studio Code), og du skal åbne din terminal (eller: kommandoprompt).
|
||||
|
||||
Naviger til [github.com](https://github.com/) og opret en konto, hvis du ikke allerede har gjort det, eller log ind og udfyld din profil.
|
||||
|
||||
✅ GitHub er ikke det eneste kodelager i verden; der er andre, men GitHub er det mest kendte.
|
||||
|
||||
### Forberedelse
|
||||
|
||||
Du skal bruge både en mappe med et kodeprojekt på din lokale maskine (laptop eller pc) og et offentligt repository på GitHub, som vil fungere som et eksempel på, hvordan man bidrager til andres projekter.
|
||||
|
||||
---
|
||||
|
||||
## Håndtering af kode
|
||||
|
||||
Lad os sige, at du har en mappe lokalt med et kodeprojekt, og at du vil begynde at spore dine fremskridt ved hjælp af git - versionsstyringssystemet. Nogle mennesker sammenligner det at bruge git med at skrive et kærlighedsbrev til sit fremtidige jeg. Når du læser dine commit-meddelelser dage, uger eller måneder senere, vil du kunne huske, hvorfor du tog en beslutning eller "rullede" en ændring tilbage - det vil sige, når du skriver gode "commit-meddelelser".
|
||||
|
||||
### Opgave: Lav et repository og commit kode
|
||||
|
||||
> Tjek videoen ud
|
||||
>
|
||||
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
|
||||
|
||||
|
||||
1. **Opret et repository på GitHub**. På GitHub.com finder du knappen **new repo** under fanen repositories eller i navigationslinjen øverst til højre.
|
||||
|
||||
1. Giv dit repository (mappe) et navn.
|
||||
1. Vælg **opret repository**.
|
||||
|
||||
1. **Naviger til din arbejdsmappe**. I din terminal skal du skifte til den mappe (også kendt som biblioteket), du vil begynde at spore. Skriv:
|
||||
|
||||
```bash
|
||||
cd [navn på din mappe]
|
||||
```
|
||||
|
||||
1. **Initialiser et git-repository**. I din projekttype:
|
||||
|
||||
```bash
|
||||
git init
|
||||
```
|
||||
|
||||
1. **Tjek status**. For at tjekke status for dit repository skriver du:
|
||||
|
||||
```bash
|
||||
git status
|
||||
```
|
||||
|
||||
Outputtet kan se nogenlunde sådan ud:
|
||||
|
||||
```output
|
||||
Changes not staged for commit:
|
||||
(use "git add <file>..." to update what will be committed)
|
||||
(use "git checkout -- <file>..." to discard changes in working directory)
|
||||
|
||||
modified: file.txt
|
||||
modified: file2.txt
|
||||
```
|
||||
|
||||
Typically a `git status` command tells you things like what files are ready to be _saved_ to the En `git status`-kommando fortæller dig typisk ting som, hvilke filer der er klar til at blive _gemt_ i repoen eller har ændringer, som du måske ønsker at bevare.
|
||||
|
||||
1. **Tilføj alle filer til sporing**.
|
||||
Dette kaldes også staging files/tilføjelse af filer til staging-området.
|
||||
|
||||
```bash
|
||||
git add .
|
||||
```
|
||||
|
||||
Argumentet `git add` plus `.` angiver, at alle dine filer og ændringer skal spores.
|
||||
|
||||
|
||||
|
||||
1. **Tilføj udvalgte filer til sporing**.
|
||||
|
||||
```bash
|
||||
git add [fil- eller mappenavn]
|
||||
```
|
||||
|
||||
Dette hjælper os med kun at tilføje udvalgte filer til staging-området, når vi ikke ønsker at overføre alle filer på én gang.
|
||||
|
||||
1. **Fjern (unstage) alle filer fra scenen**
|
||||
|
||||
```bash
|
||||
git reset
|
||||
```
|
||||
|
||||
Denne kommando hjælper os med at fjerne alle filer fra scenen på én gang.
|
||||
|
||||
1. **Fjern (unstage) en bestemt fil**
|
||||
|
||||
```bash
|
||||
git reset [fil- eller mappenavn]
|
||||
```
|
||||
|
||||
Denne kommando hjælper os med kun at fjerne en bestemt fil på én gang, som vi ikke ønsker at inkludere i den næste commit.
|
||||
|
||||
1. **Fastholdelse af dit arbejde**. På dette tidspunkt har du tilføjet filerne til et såkaldt _staging area_. Et sted, hvor Git sporer dine filer. For at gøre ændringen permanent er du nødt til at _committe_ filerne. Det gør du ved at oprette en _commit_ med kommandoen `git commit`. En _commit_ repræsenterer et gemmepunkt i dit repos historik. Skriv følgende for at oprette en _commit_:
|
||||
|
||||
```bash
|
||||
git commit -m "første commit"
|
||||
```
|
||||
|
||||
Dette committer alle dine filer og tilføjer beskeden "first commit". For fremtidige commit-meddelelser skal du være mere beskrivende i din beskrivelse for at formidle, hvilken type ændring du har foretaget.c
|
||||
|
||||
1. **Forbind dit lokale Git-repo med GitHub**. Et Git-repo er godt på din maskine, men på et tidspunkt vil du gerne have en backup af dine filer et sted og også invitere andre til at arbejde sammen med dig på dit repo. Et godt sted at gøre det er GitHub. Husk, at vi allerede har oprettet et repo på GitHub, så det eneste, vi skal gøre, er at forbinde vores lokale Git-repo med GitHub. Kommandoen `git remote add` vil gøre netop det. Skriv følgende kommando:
|
||||
|
||||
> Bemærk, før du skriver kommandoen, skal du gå til din GitHub repo-side for at finde repository-URL'en. Du skal bruge den i kommandoen nedenfor. Erstat ``https://github.com/username/repository_name.git``` med din GitHub-URL.
|
||||
|
||||
```bash
|
||||
git remote add origin https://github.com/username/repository_name.git
|
||||
```
|
||||
|
||||
Dette opretter en _remote_, eller forbindelse, med navnet "origin", der peger på det GitHub-repositorium, du oprettede tidligere.
|
||||
|
||||
1. **Send lokale filer til GitHub**. Indtil videre har du oprettet en _forbindelse_ mellem det lokale repo og GitHub-repoet. Lad os sende disse filer til GitHub med følgende kommando `git push`, sådan her:
|
||||
|
||||
> Bemærk, din branches navn kan som standard være forskelligt fra ```main```.
|
||||
|
||||
```bash
|
||||
git push -u origin main
|
||||
```
|
||||
|
||||
Dette sender dine commits i din "main"-gren til GitHub.
|
||||
|
||||
2. **For at tilføje flere ændringer**. Hvis du vil fortsætte med at lave ændringer og skubbe dem til GitHub, skal du bare bruge de følgende tre kommandoer:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "skriv din commit-besked her"
|
||||
git push
|
||||
```
|
||||
|
||||
> Tip: Du kan også indføre en `.gitignore`-fil for at forhindre filer, du ikke ønsker at spore, i at dukke op på GitHub - som den note-fil, du gemmer i den samme mappe, men som ikke hører hjemme i et offentligt repository. Du kan finde skabeloner til `.gitignore`-filer på [.gitignore templates](https://github.com/github/gitignore).
|
||||
|
||||
#### Commit-meddelelser
|
||||
|
||||
En god Git commit-emnelinje afslutter følgende sætning:
|
||||
Hvis den anvendes, vil dette commit <din emnelinje her>.
|
||||
|
||||
I emnet skal du bruge imperativ, nutid: "change", ikke "changed" eller "changes".
|
||||
Som i emnet skal du i brødteksten (valgfri) også bruge imperativ, nutid. Brødteksten skal indeholde motivationen for ændringen og sætte den i kontrast til tidligere adfærd. Du forklarer `hvorfor`, ikke `hvordan`.
|
||||
|
||||
✅ Brug et par minutter på at surfe rundt på GitHub. Kan du finde en rigtig god commit-besked? Kan du finde en virkelig minimal en? Hvilke oplysninger synes du er de vigtigste og mest nyttige at formidle i en commit-meddelelse?
|
||||
|
||||
### Opgave: Samarbejde
|
||||
|
||||
Hovedårsagen til at lægge ting på GitHub var at gøre det muligt at samarbejde med andre udviklere.
|
||||
|
||||
## Arbejde på projekter med andre
|
||||
|
||||
> Tjek videoen ud
|
||||
>
|
||||
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
|
||||
|
||||
I dit repository skal du navigere til `Insights > Community` for at se, hvordan dit projekt ligger i forhold til de anbefalede community-standarder.
|
||||
|
||||
Her er nogle ting, der kan forbedre dit GitHub repo:
|
||||
- **Beskrivelse**. Har du tilføjet en beskrivelse af dit projekt?
|
||||
- **README**. Har du tilføjet en README? GitHub giver vejledning i at skrive en [README] (https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
|
||||
- **Retningslinjer for bidrag**. Har dit projekt [retningslinjer for bidrag](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon),
|
||||
- **Code of Conduct**. en [Code of Conduct](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/),
|
||||
- **Licens**. Måske vigtigst af alt, en [licens](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
|
||||
|
||||
Alle disse ressourcer vil gavne onboarding af nye teammedlemmer. Og det er typisk den slags ting, nye bidragydere kigger på, før de overhovedet kigger på din kode, for at finde ud af, om dit projekt er det rigtige sted for dem at bruge deres tid.
|
||||
|
||||
✅ README-filer, selvom de tager tid at forberede, bliver ofte forsømt af travle vedligeholdere. Kan du finde et eksempel på en særligt beskrivende en? Bemærk: der er nogle [værktøjer til at hjælpe med at skabe gode README'er] (https://www.makeareadme.com/), som du måske vil prøve.
|
||||
|
||||
### Opgave: Flet noget kode
|
||||
|
||||
Contributing docs hjælper folk med at bidrage til projektet. Den forklarer, hvilke typer bidrag du leder efter, og hvordan processen fungerer. Bidragsydere skal igennem en række trin for at kunne bidrage til dit repo på GitHub:
|
||||
|
||||
|
||||
1. **Forking af dit repo** Du vil sandsynligvis gerne have folk til at _forke_ dit projekt. At forke betyder, at man opretter en kopi af dit repository på sin GitHub-profil.
|
||||
1. **Klon**. Derfra vil de klone projektet til deres lokale maskine.
|
||||
1. **Opret en gren**. Du vil bede dem om at oprette en _branch_ til deres arbejde.
|
||||
1. **Fokuser deres ændringer på ét område**. Bed bidragsyderne om at koncentrere deres bidrag om én ting ad gangen - på den måde er chancerne for, at du kan _fusionere_ i deres arbejde, større. Forestil dig, at de skriver en fejlrettelse, tilføjer en ny funktion og opdaterer flere tests - hvad nu, hvis du kun vil eller kan implementere 2 ud af 3 eller 1 ud af 3 ændringer?
|
||||
|
||||
✅ Forestil dig en situation, hvor branches er særligt kritiske for at skrive og sende god kode. Hvilke use cases kan du komme i tanke om?
|
||||
|
||||
> Bemærk, vær den forandring, du ønsker at se i verden, og opret også grene til dit eget arbejde. Alle commits, du laver, vil blive lavet på den gren, du i øjeblikket er "checket ud" til. Brug `git status` til at se, hvilken gren det er.
|
||||
|
||||
Lad os gennemgå en arbejdsgang for en bidragyder. Antag, at bidragyderen allerede har _forked_ og _cloned_ repoen, så de har en Git repo klar til at arbejde på, på deres lokale maskine:
|
||||
|
||||
1. **Opret en gren (branch)**. Brug kommandoen `git branch` til at oprette en gren, der skal indeholde de ændringer, de har tænkt sig at bidrage med:
|
||||
|
||||
```bash
|
||||
git branch [branch-name]
|
||||
```
|
||||
|
||||
1. **Skift til arbejdsgren**. Skift til den angivne gren, og opdater arbejdsmappen med `git switch`:
|
||||
|
||||
```bash
|
||||
git switch [branch-name]
|
||||
```
|
||||
|
||||
1. **Gør arbejdet**. På dette tidspunkt vil du tilføje dine ændringer. Glem ikke at fortælle Git om det med følgende kommandoer:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "mine ændringer"
|
||||
```
|
||||
|
||||
Sørg for at give din commit et godt navn, både for din egen skyld og for vedligeholderen af det repo, du hjælper på.
|
||||
|
||||
1. **Kombiner dit arbejde med `hovedgrenen`**. På et tidspunkt er du færdig med at arbejde, og du ønsker at kombinere dit arbejde med `main` branch. `main` branch kan have ændret sig i mellemtiden, så sørg for først at opdatere den til den nyeste med følgende kommandoer:
|
||||
|
||||
```bash
|
||||
git switch main
|
||||
git pull
|
||||
```
|
||||
|
||||
På dette tidspunkt vil du sikre dig, at eventuelle _konflikter_, situationer, hvor Git ikke nemt kan _kombinere_ ændringerne, sker i din arbejdsgren. Kør derfor følgende kommandoer:
|
||||
|
||||
```bash
|
||||
git switch [branch_name]
|
||||
git merge main
|
||||
```
|
||||
|
||||
Dette vil bringe alle ændringer fra `main` ind i din gren, og forhåbentlig kan du bare fortsætte. Hvis ikke, vil VS Code fortælle dig, hvor Git er _forvirret_, og du skal bare ændre de berørte filer for at sige, hvilket indhold der er det mest nøjagtige.
|
||||
|
||||
1. **Send dit arbejde til GitHub**. At sende dit arbejde til GitHub betyder to ting. Skubbe din gren til dit repo og derefter åbne en PR, Pull Request.
|
||||
|
||||
```bash
|
||||
git push --set-upstream origin [branch-name]
|
||||
```
|
||||
|
||||
Ovenstående kommando opretter grenen på dit forkede repo.
|
||||
|
||||
1. **Åbn en PR**. Dernæst skal du åbne en PR. Det gør du ved at navigere til det forkede repo på GitHub. Du vil se en indikation på GitHub, hvor den spørger, om du vil oprette en ny PR, du klikker på det, og du bliver ført til en grænseflade, hvor du kan ændre commit message-titlen, give den en mere passende beskrivelse. Nu vil vedligeholderen af det repo, du forkede, se denne PR, og _fingers crossed_ vil de værdsætte og _merge_ din PR. Du er nu en bidragyder, yay :)
|
||||
|
||||
1. **Ryd op**. Det anses for at være god praksis at _rydde op_, når du har flettet en PR. Du ønsker at rydde op i både din lokale gren og den gren, du har skubbet til GitHub. Lad os først slette den lokalt med følgende kommando:
|
||||
|
||||
```bash
|
||||
git branch -d [branch-name]
|
||||
```
|
||||
|
||||
Sørg derefter for at gå ind på GitHub-siden for det forkede repo og fjern den remote branch, du lige har skubbet til det.
|
||||
|
||||
`Pull request` virker som et fjollet udtryk, fordi du i virkeligheden ønsker at skubbe dine ændringer til projektet. Men vedligeholderen (projektejeren) eller kerneteamet er nødt til at overveje dine ændringer, før de flettes med projektets "hovedgren", så du anmoder i virkeligheden om en ændringsbeslutning fra en vedligeholder.
|
||||
|
||||
En pull request er stedet, hvor man kan sammenligne og diskutere de forskelle, der er introduceret på en branch, med reviews, kommentarer, integrerede tests og meget mere. En god pull request følger nogenlunde de samme regler som en commit-meddelelse. Du kan tilføje en reference til et problem i issue tracker, når dit arbejde f.eks. løser et problem. Dette gøres ved hjælp af et `#` efterfulgt af nummeret på dit problem. For eksempel `#97`.
|
||||
|
||||
🤞Vi krydser fingre for, at alle checks går igennem, og at projektejerne fletter dine ændringer ind i projektet🤞.
|
||||
|
||||
Opdater din nuværende lokale arbejdsgren med alle nye commits fra den tilsvarende fjerngren på GitHub:
|
||||
|
||||
`git pull`
|
||||
|
||||
## Sådan bidrager du til open source
|
||||
|
||||
Lad os først finde et repository (eller **repo**) på GitHub, som er interessant for dig, og som du gerne vil bidrage med en ændring til. Du skal kopiere dets indhold til din maskine.
|
||||
|
||||
✅ En god måde at finde 'begyndervenlige' repos på er at [søge efter tagget 'good-first-issue'] (https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
|
||||
|
||||
|
||||
|
||||
Der er flere måder at kopiere kode på. En måde er at "klone" indholdet af repository'et ved hjælp af HTTPS, SSH eller GitHub CLI (Command Line Interface).
|
||||
|
||||
Åbn din terminal og klon depotet på denne måde:
|
||||
`git clone https://github.com/ProjectURL`
|
||||
|
||||
For at arbejde på projektet skal du skifte til den rigtige mappe:
|
||||
`cd ProjectURL`
|
||||
|
||||
Du kan også åbne hele projektet ved hjælp af [Codespaces](https://github.com/features/codespaces), GitHubs indlejrede kodeeditor / cloud-udviklingsmiljø, eller [GitHub Desktop](https://desktop.github.com/).
|
||||
|
||||
Endelig kan du downloade koden i en zippet mappe.
|
||||
|
||||
### Et par mere interessante ting om GitHub
|
||||
|
||||
Du kan stjernemarkere, overvåge og/eller "forke" ethvert offentligt repositorium på GitHub. Du kan finde dine stjernemarkerede repositories i rullemenuen øverst til højre. Det er ligesom bogmærker, men for kode.
|
||||
|
||||
Projekter har en issue tracker, for det meste på GitHub under fanen "Issues", medmindre andet er angivet, hvor folk diskuterer problemer relateret til projektet. Og fanen Pull Requests er der, hvor folk diskuterer og gennemgår ændringer, der er undervejs.
|
||||
|
||||
Projekter kan også have diskussioner i fora, mailinglister eller chatkanaler som Slack, Discord eller IRC.
|
||||
|
||||
✅ Tag et kig på dit nye GitHub-repo, og prøv et par ting, som at redigere indstillinger, tilføje oplysninger til dit repo og oprette et projekt (som en Kanban-tavle). Der er meget, du kan gøre!
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Udfordring
|
||||
|
||||
Gå sammen med en ven om at arbejde på hinandens kode. Opret et projekt i fællesskab, fork kode, opret branches og flet ændringer.
|
||||
|
||||
## Quiz efter undervisning
|
||||
[Quiz efter forelæsning](https://ashy-river-0debb7803.1.azurestaticapps.net/quiz/4)
|
||||
|
||||
## Gennemgang og selvstudium
|
||||
|
||||
Læs mere om [bidrag til open source-software](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
|
||||
|
||||
[Git cheatsheet](https://training.github.com/downloads/github-git-cheat-sheet/).
|
||||
|
||||
Øvelse, øvelse, øvelse. GitHub har gode læringsstier tilgængelige via [skills.github.com](https://skills.github.com):
|
||||
|
||||
- [Første uge på GitHub](https://skills.github.com/#first-week-on-github)
|
||||
|
||||
Du kan også finde mere avancerede kurser.
|
||||
|
||||
## Opgave
|
||||
|
||||
Gennemfør [kurset First Week on GitHub](https://skills.github.com/#first-week-on-github)
|
||||
@ -0,0 +1,231 @@
|
||||
# Oprettelse af tilgængelige websider
|
||||
|
||||
|
||||
> Sketchnote af [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## Quiz før undervisning
|
||||
[Quiz før undervisning](https://ashy-river-0debb7803.1.azurestaticapps.net/quiz/5)
|
||||
|
||||
> The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.
|
||||
>
|
||||
> \- Sir Timothy Berners-Lee, W3C-direktør og opfinder af World Wide Web
|
||||
|
||||
Dette citat fremhæver perfekt vigtigheden af at skabe tilgængelige hjemmesider. En applikation, der ikke kan tilgås af alle, er pr. definition ekskluderende. Som webudviklere bør vi altid have tilgængelighed i tankerne. Ved at have dette fokus fra begyndelsen vil du være godt på vej til at sikre, at alle kan få adgang til de sider, du opretter. I denne lektion lærer du om de værktøjer, der kan hjælpe dig med at sikre, at dine webaktiver er tilgængelige, og hvordan du bygger med tilgængelighed i tankerne.
|
||||
|
||||
> Du kan tage denne lektion på [Microsoft Learn](https://docs.microsoft.com/learn/modules/web-development-101/accessibility/?WT.mc_id=academic-77807-sagibbon)!
|
||||
|
||||
## Værktøjer, der skal bruges
|
||||
|
||||
### Skærmlæsere
|
||||
|
||||
Et af de mest kendte tilgængelighedsværktøjer er skærmlæsere.
|
||||
|
||||
[Screen readers](https://en.wikipedia.org/wiki/Screen_reader) er almindeligt anvendte klienter til personer med nedsat syn. Når vi bruger tid på at sikre, at en browser korrekt formidler de oplysninger, vi ønsker at dele, skal vi også sikre, at en skærmlæser gør det samme.
|
||||
|
||||
Helt grundlæggende vil en skærmlæser læse en side fra top til bund med lyd. Hvis din side kun består af tekst, vil læseren formidle informationen på samme måde som en browser. Selvfølgelig er websider sjældent ren tekst; de vil indeholde links, grafik, farver og andre visuelle komponenter. Der skal udvises omhu for at sikre, at disse oplysninger læses korrekt af en skærmlæser.
|
||||
|
||||
Enhver webudvikler bør gøre sig bekendt med en skærmlæser. Som fremhævet ovenfor, er det den klient, dine brugere vil bruge. På samme måde som du er bekendt med, hvordan en browser fungerer, bør du lære, hvordan en skærmlæser fungerer. Heldigvis er skærmlæsere indbygget i de fleste operativsystemer.
|
||||
|
||||
Nogle browsere har også indbyggede værktøjer og udvidelser, der kan læse tekst højt eller endda give nogle grundlæggende navigationsfunktioner, såsom [disse tilgængelighedsfokuserede Edge-browserværktøjer](https://support.microsoft.com/help/4000734/microsoft-edge-accessibility-features). Disse er også vigtige tilgængelighedsværktøjer, men fungerer meget forskelligt fra skærmlæsere, og de bør ikke forveksles med testværktøjer til skærmlæsere.
|
||||
|
||||
✅ Prøv en skærmlæser og en browsertekstlæser. På Windows er [Narrator](https://support.microsoft.com/windows/complete-guide-to-narrator-e4397a0d-ef4f-b386-d8ae-c172f109bdb1/?WT.mc_id=academic-77807-sagibbon) inkluderet som standard, og [JAWS](https://webaim.org/articles/jaws/) og [NVDA](https://www.nvaccess.org/about-nvda/) kan også installeres. På macOS og iOS er [VoiceOver](https://support.apple.com/guide/voiceover/welcome/10) installeret som standard.
|
||||
|
||||
### Zoom
|
||||
|
||||
Et andet værktøj, der ofte bruges af mennesker med synsnedsættelse, er zoom. Den mest basale form for zoom er statisk zoom, der styres med `Control + plustegn (+)` eller ved at mindske skærmopløsningen. Denne type zoom får hele siden til at ændre størrelse, så det er vigtigt at bruge [responsivt design](https://developer.mozilla.org/docs/Learn/CSS/CSS_layout/Responsive_Design) for at give en god brugeroplevelse ved øgede zoomniveauer.
|
||||
|
||||
En anden type zoom er afhængig af specialiseret software til at forstørre et område af skærmen og panorere, ligesom når man bruger et rigtigt forstørrelsesglas. I Windows er [Magnifier](https://support.microsoft.com/windows/use-magnifier-to-make-things-on-the-screen-easier-to-see-414948ba-8b1c-d3bd-8615-0e5e32204198) indbygget, og [ZoomText](https://www.freedomscientific.com/training/zoomtext/getting-started/) er et forstørrelsesprogram fra en tredjepart med flere funktioner og en større brugerbase. Både macOS og iOS har en indbygget forstørrelsessoftware kaldet [Zoom](https://www.apple.com/accessibility/mac/vision/).
|
||||
|
||||
### Kontrasttjek
|
||||
|
||||
Farver på hjemmesider skal vælges med omhu for at imødekomme behovene hos farveblinde brugere eller folk, der har svært ved at se farver med lav kontrast.
|
||||
|
||||
✅ Test et websted, du nyder at bruge, for farvebrug med en browserudvidelse som [WCAG's color checker](https://microsoftedge.microsoft.com/addons/detail/wcag-color-contrast-check/idahaggnlnekelhgplklhfpchbfdmkjp?hl=en-US&WT.mc_id=academic-77807-sagibbon). Hvad lærer du af det?
|
||||
|
||||
### Lighthouse
|
||||
|
||||
I udviklerværktøjsområdet i din browser finder du Lighthouse-værktøjet. Dette værktøj er vigtigt for at få et første overblik over tilgængeligheden (samt andre analyser) af et websted. Selvom det er vigtigt ikke udelukkende at stole på Lighthouse, er en score på 100 % meget nyttig som udgangspunkt.
|
||||
|
||||
✅ Find Lighthouse i din browsers udviklerværktøjspanel, og kør en analyse på et hvilket som helst websted. hvad opdager du?
|
||||
|
||||
## Design for tilgængelighed
|
||||
|
||||
Tilgængelighed er et relativt stort emne. For at hjælpe dig er der mange ressourcer til rådighed.
|
||||
|
||||
- [Accessible U - University of Minnesota](https://accessibility.umn.edu/your-role/web-developers)
|
||||
|
||||
Vi vil ikke kunne dække alle aspekter af at skabe tilgængelige sider, men nedenfor er nogle af de grundlæggende principper, du bør implementere. At designe en tilgængelig side fra starten er **altid** lettere end at gå tilbage til en eksisterende side for at gøre den tilgængelig.
|
||||
|
||||
## Gode principper for visning
|
||||
|
||||
### Farvesikre paletter
|
||||
|
||||
Folk ser verden på forskellige måder, og det gælder også farver. Når du vælger et farveskema til din hjemmeside, bør du sikre dig, at det er tilgængeligt for alle. Et godt [værktøj til at generere farvepaletter er Color Safe](http://colorsafe.co/).
|
||||
|
||||
✅ Identificer et websted, der er meget problematisk i sin brug af farver. Hvorfor er den det?
|
||||
|
||||
### Brug korrekt HTML
|
||||
|
||||
Med CSS og JavaScript er det muligt af omdanne alle elementer til enhver type af kontrolelement. `<span>` kan bruge til at skabe et `<button>` element, og `<b>` kunne omdannes til et hyperlink. Selv om det kan gøre det nemmere i forhold til styling, bærer det ikke meget mening videre til en skærmlæser. Brug den hensigtsmæsige HTML når du skaber kontrolelementer på din side. Hvis du vil vise et hyperlink så brug `<a>`. At bruge den rigtige HTML til den rigtige kontrol kaldes at gøre brug af semantisk HTML (Semantic HTML).
|
||||
|
||||
✅ Gå ind på et hvilket som helst websted, og se, om designerne og udviklerne bruger HTML korrekt. Kan du finde en knap, der burde være et link? Tip: Højreklik og vælg 'View Page Source' i din browser for at se den underliggende kode.
|
||||
|
||||
### Skab et beskrivende overskriftshierarki
|
||||
|
||||
Skærmlæserbrugere [er meget afhængige af overskrifter](https://webaim.org/projects/screenreadersurvey8/#finding) for at finde information og navigere gennem en side. At skrive beskrivende overskriftsindhold og bruge semantiske overskriftskoder er vigtigt for at skabe en let navigerbar side for skærmlæserbrugere.
|
||||
|
||||
### Brug gode visuelle ledetråde
|
||||
|
||||
CSS giver fuld kontrol over udseendet af ethvert element på en side. Du kan lave tekstbokse uden omrids eller hyperlinks uden understregning. Desværre kan fjernelse af disse ledetråde gøre det mere udfordrende for en person, der er afhængig af dem, at kunne genkende typen af kontrol.
|
||||
|
||||
## Vigtigheden af linktekst
|
||||
|
||||
Hyperlinks er kernen i at navigere på nettet. Derfor er det vigtigt at sikre, at en skærmlæser kan læse links korrekt, så alle brugere kan navigere rundt på din hjemmeside.
|
||||
|
||||
### Skærmlæsere og links
|
||||
|
||||
Som man kan forvente, læser skærmlæsere linktekst på samme måde, som de læser enhver anden tekst på siden. Med dette i tankerne kan teksten, der demonstreres nedenfor, føles helt acceptabel.
|
||||
|
||||
> Den lille pingvin, også kendt som dværgpingvinen, er den mindste pingvin i verden. [Klik her](https://en.wikipedia.org/wiki/Little_penguin) for mere information.
|
||||
|
||||
> Den lille pingvin, også kendt som dværgpingvinen, er den mindste pingvin i verden. Besøg https://en.wikipedia.org/wiki/Little_penguin for mere information.
|
||||
|
||||
> **BEMÆRK** Som du vil læse nu, bør du **aldrig** oprette links, der ser ud som ovenstående.
|
||||
|
||||
Husk, at skærmlæsere er et andet interface end browsere med et andet sæt funktioner.
|
||||
|
||||
### Problemet med at bruge URL'en
|
||||
|
||||
Skærmlæsere læser teksten. Hvis der er en URL i teksten, vil skærmlæseren læse URL'en. Generelt formidler URL'en ikke meningsfuld information, og den kan lyde irriterende. Du har måske oplevet dette, hvis din telefon nogensinde har læst en tekstbesked med en URL op.
|
||||
|
||||
### Problemet med "klik her"
|
||||
|
||||
Skærmlæsere har også mulighed for kun at læse hyperlinks på en side, på samme måde som en seende person ville scanne en side for links. Hvis linkteksten altid er "klik her", vil brugeren kun høre "klik her, klik her, klik her, klik her, klik her, ...". Alle links er nu umulige at skelne fra hinanden.
|
||||
|
||||
### God linktekst
|
||||
|
||||
En god linktekst beskriver kort, hvad der er på den anden side af linket. I eksemplet ovenfor, der handler om små pingviner, er linket til Wikipedia-siden om arten. Sætningen *lille pingviner* ville være en perfekt linktekst, da den gør det klart, hvad man vil lære om, hvis man klikker på linket - små pingviner.
|
||||
|
||||
> Den [lille pingvin](https://en.wikipedia.org/wiki/Little_penguin), også kendt som dværgpingvinen, er den mindste pingvin i verden.
|
||||
|
||||
✅ Surf rundt på nettet i et par minutter for at finde sider, der bruger obskure linkstrategier. Sammenlign dem med andre, bedre linkede sider. Hvad lærer du af det?
|
||||
|
||||
#### Noter til søgemaskiner
|
||||
|
||||
Som en ekstra bonus for at sikre, at din hjemmeside er tilgængelig for alle, hjælper du også søgemaskinerne med at navigere på din hjemmeside. Søgemaskiner bruger linktekst til at lære sidernes emner at kende. Så at bruge god linktekst hjælper alle!
|
||||
|
||||
### ARIA
|
||||
|
||||
Forestil dig følgende side:
|
||||
|
||||
| Produkt | Beskrivelse | Ordre |
|
||||
| ------------ | ------------------ | ------------ |
|
||||
| Widget | [Beskrivelse]('#') | [Ordre]('#') |
|
||||
| Super widget | [Beskrivelse]('#') | [Ordre]('#') |
|
||||
|
||||
I dette eksempel giver det mening at duplikere teksten i beskrivelse og rækkefølge for en person, der bruger en browser. Men en person, der bruger en skærmlæser, vil kun høre ordene *description* og *order* gentaget uden kontekst.
|
||||
|
||||
For at understøtte denne type scenarier understøtter HTML et sæt attributter, der kaldes [Accessible Rich Internet Applications (ARIA)](https://developer.mozilla.org/docs/Web/Accessibility/ARIA). Disse attributter giver dig mulighed for at give yderligere oplysninger til skærmlæsere.
|
||||
|
||||
> **BEMÆRK**: Som mange andre aspekter af HTML kan understøttelsen af browsere og skærmlæsere variere. De fleste mainline-klienter understøtter dog ARIA-attributter.
|
||||
|
||||
Du kan bruge `aria-label` til at beskrive linket, når formatet på siden ikke tillader det. Beskrivelsen af widgetten kan indstilles som
|
||||
|
||||
``` html
|
||||
<a href="#" aria-label="Widget beskrivelse">beskrivelse</a>
|
||||
```
|
||||
|
||||
✅ Generelt erstatter brugen af semantisk markup som beskrevet ovenfor brugen af ARIA, men nogle gange er der ingen semantisk ækvivalent for forskellige HTML-widgets. Et godt eksempel er et træ. Der er ingen HTML-ækvivalent for et træ, så du identificerer den generiske `<div>` for dette element med en korrekt rolle og aria-værdier. [MDN-dokumentation om ARIA](https://developer.mozilla.org/docs/Web/Accessibility/ARIA) indeholder flere nyttige oplysninger.
|
||||
|
||||
```html
|
||||
<h2 id="tree-label">File Viewer</h2>
|
||||
<div role="tree" aria-labelledby="tree-label">
|
||||
<div role="treeitem" aria-expanded="false" tabindex="0">Uploads</div>
|
||||
</div>
|
||||
```
|
||||
|
||||
## Billeder
|
||||
|
||||
Det siger sig selv, at skærmlæsere ikke automatisk kan læse, hvad der er i et billede. Det kræver ikke meget arbejde at sikre, at billeder er tilgængelige - det er det, `alt`-attributten handler om. Alle meningsfulde billeder skal have en `alt` til at beskrive, hvad de er.
|
||||
Billeder, der er rent dekorative, skal have deres `alt`-attribut sat til en tom streng: `alt=""`. Dette forhindrer skærmlæsere i unødigt at annoncere det dekorative billede.
|
||||
|
||||
✅ Som du måske forventer, er søgemaskiner heller ikke i stand til at forstå, hvad der er i et billede. De bruger også alt-tekst. Så endnu en gang giver det ekstra bonus at sikre, at din side er tilgængelig!
|
||||
|
||||
## Tastaturet
|
||||
|
||||
Nogle brugere kan ikke bruge en mus eller en trackpad og er i stedet afhængige af tastaturinteraktioner for at kunne tabbe fra et element til det næste. Det er vigtigt, at din hjemmeside præsenterer dit indhold i en logisk rækkefølge, så en tastaturbruger kan få adgang til hvert interaktivt element, når de bevæger sig ned gennem et dokument. Hvis du bygger dine websider med semantisk markup og bruger CSS til at style deres visuelle layout, bør dit site være tastatur-navigerbart, men det er vigtigt at teste dette aspekt manuelt. Læs mere om [keyboard navigation strategies](https://webaim.org/techniques/keyboard/).
|
||||
|
||||
✅ Gå ind på et hvilket som helst websted, og prøv at navigere gennem det udelukkende ved hjælp af dit tastatur. Hvad virker, hvad virker ikke? Og hvorfor?
|
||||
|
||||
## Resumé
|
||||
|
||||
Et web, der er tilgængeligt for nogle, er ikke et ægte "world-wide web". Den bedste måde at sikre, at de sider, du opretter, er tilgængelige, er at indarbejde best practices for tilgængelighed fra starten. Selvom der er ekstra trin involveret, vil det at indarbejde disse færdigheder i dit workflow nu betyde, at alle sider, du opretter, vil være tilgængelige.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Udfordring
|
||||
|
||||
Tag denne HTML og omskriv den, så den bliver så tilgængelig som muligt med de strategier, du har lært.
|
||||
|
||||
```html
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>
|
||||
Example
|
||||
</title>
|
||||
<link href='../assets/style.css' rel='stylesheet' type='text/css'>
|
||||
</head>
|
||||
<body>
|
||||
<div class="site-header">
|
||||
<p class="site-title">Turtle Ipsum</p>
|
||||
<p class="site-subtitle">Verdens førende skildpadde fanklub</p>
|
||||
</div>
|
||||
<div class="main-nav">
|
||||
<p class="nav-header">Resources</p>
|
||||
<div class="nav-list">
|
||||
<p class="nav-item nav-item-bull"><a href="https://www.youtube.com/watch?v=CMNry4PE93Y">"Jeg elsker skildspadder"</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="https://en.wikipedia.org/wiki/Turtle">Grundlæggende viden om skildpadder</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="https://en.wikipedia.org/wiki/Turtles_(chocolate)">Chokoladeskildpadder</a></p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="main-content">
|
||||
<div>
|
||||
<p class="page-title">Velkommen til Turtle Ipsum.
|
||||
<a href="">Klik her</a> for at lære mere.
|
||||
</p>
|
||||
<p class="article-text">
|
||||
Turtle ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="footer">
|
||||
<div class="footer-section">
|
||||
<span class="button">Skriv dig op til skildpadde nyheder</span>
|
||||
</div><div class="footer-section">
|
||||
<p class="nav-header footer-title">
|
||||
Interne sider
|
||||
</p>
|
||||
<div class="nav-list">
|
||||
<p class="nav-item nav-item-bull"><a href="../">Index</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="../semantic">Semantisk eksempel</a></p>
|
||||
</div>
|
||||
</div>
|
||||
<p class="footer-copyright">© 2016 Instrument</span>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
## Quiz efter undervisning
|
||||
[Quiz efter forelæsning](https://ashy-river-0debb7803.1.azurestaticapps.net/quiz/6)
|
||||
|
||||
## Gennemgang og selvstudium
|
||||
|
||||
Mange regeringer har love om tilgængelighedskrav. Læs op på dit hjemlands tilgængelighedslove. Hvad er dækket, og hvad er ikke? Et eksempel er [dette regeringswebsted](https://accessibility.blog.gov.uk/).
|
||||
|
||||
## Opgave
|
||||
|
||||
[Analyser et ikke-tilgængeligt websted](assignment.md)
|
||||
|
||||
Kreditering: [Turtle Ipsum](https://github.com/Instrument/semantic-html-sample) af Instrument
|
||||
@ -0,0 +1,17 @@
|
||||
# Kom godt i gang med webudvikling
|
||||
|
||||
I denne del af kurset vil du blive introduceret til ikke-projektbaserede koncepter, der er vigtige for at blive en professionel udvikler.
|
||||
|
||||
### Emner
|
||||
|
||||
1. [Introduktion til programmeringssprog og værktøjer](../1-intro-to-programming-languages/translations/README.da.md)
|
||||
2. [Introduktion til GitHub](../2-github-basics/translations/README.da.md)
|
||||
3. [Grundlæggende om tilgængelighed](../3-accessibility/translations/README.da.md)
|
||||
|
||||
### Credits
|
||||
|
||||
Introduktion til programmeringssprog og værktøjer blev skrevet med ♥️ af [Jasmine Greenaway](https://twitter.com/paladique)
|
||||
|
||||
Introduction til GitHub blev skrevet med ♥️ af [Floor Drees](https://twitter.com/floordrees)
|
||||
|
||||
Grundlæggende om tilgængelighed blev skrevet med ♥️ af [Christopher Harrison](https://twitter.com/geektrainer)
|
||||
Loading…
Reference in new issue