mirror of
https://github.com/microsoft/Web-Dev-For-Beginners.git
synced 2025-08-18 20:41:25 +02:00
Merge branch 'main' of https://github.com/microsoft/Web-Dev-For-Beginners into main
This commit is contained in:
Sanjay
@@ -1,18 +0,0 @@
|
||||
*Selesaikan kuis ini bersama dengan kiriman Anda dengan memeriksa satu jawaban per pertanyaan.*
|
||||
|
||||
1. Bahasa apa yang kemungkinan besar akan Anda gunakan untuk membuat situs web?
|
||||
|
||||
- [ ] Machine Code (Kode Mesin)
|
||||
- [ ] JavaScript
|
||||
- [ ] Bash
|
||||
|
||||
2. Lingkungan pengembangan unik untuk setiap pengembang
|
||||
|
||||
- [ ] Benar
|
||||
- [ ] Salah
|
||||
|
||||
3. Apa yang akan dilakukan pengembang untuk memperbaiki kode buggy (mudah rusak)?
|
||||
|
||||
- [ ] Syntax highlighting (Penyorotan sintaks)
|
||||
- [ ] Debugging
|
||||
- [ ] Code formatting (Pemformatan kode)
|
||||
@@ -1,18 +0,0 @@
|
||||
*Selesaikan kuis ini di kelas*
|
||||
|
||||
1. Sebuah program dapat dibuat tanpa pembuatnya menulis kode apapun
|
||||
|
||||
- [ ] Benar
|
||||
- [ ] Salah
|
||||
|
||||
2. Bahasa tingkat rendah adalah pilihan populer untuk:
|
||||
|
||||
- [ ] Website
|
||||
- [ ] Hardware
|
||||
- [ ] Perangkat lunak permainan video
|
||||
|
||||
3. Manakah dari alat berikut yang kemungkinan besar ada di lingkungan pengembang web?
|
||||
|
||||
- [ ] Hardware, like a Raspberry Pi
|
||||
- [ ] Browser DevTools
|
||||
- [ ] Operating system documentation
|
||||
@@ -6,7 +6,8 @@ Pelajaran ini mencakup dasar-dasar bahasa pemrograman. Topik yang dibahas di sin
|
||||
> Catatan sketsa oleh [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## Kuis Pra-Kuliah
|
||||
[Kuis pra-kuliah](.github/pre-lecture-quiz.id.md)
|
||||
|
||||
[Kuis pra-kuliah](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/1?loc=id)
|
||||
|
||||
## Pengantar
|
||||
|
||||
@@ -179,6 +180,10 @@ Ketika pengembang ingin mempelajari sesuatu yang baru, mereka kemungkinan besar
|
||||
|
||||
Bandingkan beberapa bahasa pemrograman. Apa saja ciri-ciri unik JavaScript vs. Java? Bagaimana dengan COBOL vs. Go?
|
||||
|
||||
## Kuis Pasca-Kuliah
|
||||
|
||||
[Kuis pasca-kuliah](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/2?loc=id)
|
||||
|
||||
## Ulasan & Belajar Mandiri
|
||||
|
||||
Pelajari sedikit tentang berbagai bahasa yang tersedia untuk programmer. Cobalah untuk menulis baris dalam satu bahasa, dan kemudian mengulanginya pada dua bahasa lainnya. Apa yang Anda pelajari?
|
||||
|
||||
@@ -0,0 +1,192 @@
|
||||
# Introduzione ai Linguaggi di Programmazione e agli Strumenti Necessari
|
||||
|
||||
Questa lezione tratta delle basi dei linguaggi di programmazione. Gli argomenti trattati qui si applicano alla maggior parte dei moderni linguaggi di programmazione di oggi. Nella sezione 'Strumenti Necessari' conoscerete utili software che vi aiuteranno come programmatore.
|
||||
|
||||
|
||||
> Sketchnote di [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## Quiz Pre-Lezione
|
||||
[Quiz Pre-Lezione](.github/pre-lecture-quiz.md)
|
||||
|
||||
## Introduzione
|
||||
|
||||
In questa lezione tratteremo di:
|
||||
|
||||
- Cos'è la programmazione?
|
||||
- Tipi di linguaggi di programmazione
|
||||
- Elementi base di un programma
|
||||
- Software utili e strumenti per lo sviluppatore professionista
|
||||
|
||||
## Cos'è la programmazione?
|
||||
|
||||
La programmazione (conosciuta anche come scrivere codice) è il processo con il quale si scrivono istruzioni a un dispositivo, tipo un computer o dispositivo mobile. Queste istruzioni vengono scritte con un linguaggio di programmazione, quindi vengono interpretate dal dispositivo. Ci si può riferire a questo insieme di istruzioni in vari modi, ma *programma*, *programma di computer*, *applicazione (app)*, ed *eseguibile* sono alcuni dei nomi più conosciuti.
|
||||
|
||||
Un *programma* può essere qualsiasi cosa che sia scritta con codice; siti web, giochi, app per telefono sono programmi. Mentre è possibile creare un programma senza scrivere codice, la logica sottostante viene interpretata dal dispositivo e quella logica è molto probabile che sia stata scritta con codice. Un programma che sta *girando* o sta*eseguendo codice* sta effettuando istruzioni. Il dispositivo con il quale state attualmente leggendo questa lezione sta eseguendo un programma per stamparla sul vostro schermo.
|
||||
|
||||
✅ Fate una piccola ricerca: quale si ritiene sia stato il primo programmatore al mondo?
|
||||
|
||||
## Linguaggi di programmazione
|
||||
|
||||
I linguaggi di programmazione servono uno scopo principale: fare in modo che gli sviluppatori costruiscano istruzioni da inviare a un dispositivo. I dispositivi possono comprendere solo codice binario (gli 1 e gli 0), e per la *maggior parte* degli sviluppatori questo non è un modo molto efficace di comunicare. I linguaggi di programmazione sono un veicolo per comunicare tra umani e computer.
|
||||
|
||||
I linguaggi di programmazione sono disponibili in diversi formati e possono servire per scopi diversi. Ad esempio, JavaScript è principalmente usato per applicazioni web, mentre Bash è principalmente usato per sistemi operativi.
|
||||
|
||||
I *linguaggi a basso livello* richiedono in genere a un dispositivo meno passi per interpretare le istruzioni rispetto ai *linguaggi di alto livello*. Tuttavia ciò che rende popolari i *linguaggi di alto livello* è la loro leggibilità e supporto. JavaScript è considerato un *linguaggio di alto livello*
|
||||
|
||||
Il codice seguente illustra le differenze tra un linguaggio ad alto livello come JavaScript e un linguaggio a basso livello come il codice assembly ARM.
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
Credeteci o no, *stanno entrambi facendo la stessa cosa*: stampare una successione di Fibonacci fino a 10.
|
||||
|
||||
✅ Una successione di Fibonacci è [definita](https://www.wikiwand.com/it/Successione_di_Fibonacci) come un insieme di numeri tali che ciascun numero è la somma dei due precedenti, a partire da 0 e 1.
|
||||
|
||||
## Elementi di un programma
|
||||
|
||||
Una singola istruzione in un programma è detta *istruzione* e in genere avrà un carattere o spaziatura di riga che identifica dove essa finisce, o *termina*. Il modo nel quale un programma termina varia per ogni linguaggio.
|
||||
|
||||
La maggior parte dei programmi dipende dall'utilizzo di dati ricevuti da un utente o altrove, dove le istruzioni potrebbero dipendere da dati per essere effettuate. I dati possono modificare il comportamento di un programma, quindi i linguaggi di programmazione sono dotati della possibilità di conservare temporaneamente dati che possono essere usati successivamente. Questi dati sono detti *variabili*. Le variabili sono istruzioni che richiedono a un dispositivo di salvare dati nella sua memoria. Le variabili nei programmi sono simili a quelle dell'algebra, dove devono avere un nome univoco e il loro valore potrebbe mutare nel tempo.
|
||||
|
||||
Esiste la possibilità che alcune istruzioni non saranno eseguite da un dispositivo. In genere è una cosa voluta quando scritta dallo sviluppatore oppure per caso quando si verifica un errore inaspettato. Questo tipo di controllo di un'applicazione la rende più robusta e mantenibile. In genere queste modifiche nel controllo accadono quando si verificano certe condizioni. Una istruzione comune nei moderni linguaggi di programmazione per controllare come viene eseguito un programma è `if..else`.
|
||||
|
||||
✅ Saprete di più circa questo tipo di istruzione nelle lezioni successive
|
||||
|
||||
## Strumenti Necessari
|
||||
|
||||
[](https://youtube.com/watch?v=69WJeXGBdxg "Tools of the Trade")
|
||||
|
||||
In questa sezione conoscerete qualche software che potreste trovare molto utile per iniziare il vostro viaggio come programmatori professionisti.
|
||||
|
||||
Un *ambiente di sviluppo* è un insieme univoco di strumenti e caratteristiche che uno sviluppatore usa spesso quando scrive software. Alcuni di questi strumenti sono stati personalizzati per specifiche necessità dello sviluppatore e potrebbero cambiare nel tempo se lo sviluppatore cambia le priorità dei progetti di lavoro o personali, oppure quando usa un diverso linguaggio di programmazione. Gli ambienti di sviluppo sono unici tanto quanto gli sviluppatori che li utilizzano.
|
||||
|
||||
### Editor
|
||||
|
||||
Uno degli strumenti cruciali per lo sviluppo del software è l'editor. Gli editor sono dove scrivete il vostro codice e talvolta dove eseguirete il vostro codice.
|
||||
|
||||
Gli sviluppatori si affidano agli editor per qualche altra ragione aggiuntiva:
|
||||
|
||||
- *Debugging* La scoperta di bug ed errori seguendo passo passo il codice, riga per riga. Alcuni editor hanno capacita di debugging o possono essere personalizzate e aggiunte per linguaggi di programmazione specifici.
|
||||
- *Evidenziazione della Sintassi* Aggiunge colorazione e formattazione al testo del codice, rendendone più facile la lettura. La maggior parte degli editor consente la personalizzazione dell'evidenziazione della sintassi.
|
||||
- *Estensioni e integrazioni* Aggiunte specializzate per gli sviluppatori, dagli sviluppatori, per accedere a strumenti addizionali che non sono incluse come caratteristiche base dell'editor. Ad esempio molti sviluppatori hanno bisogno di un modo per documentare il proprio codice e spiegare come funziona e installeranno una estensione in grado di verificare la sintassi per trovare errori di ortografia. La maggior parte di queste aggiunte sono rivolte all'uso per un editor specifico, e molti editor hanno un modo per ricercare le estensioni disponibili.
|
||||
- *Personalizzazione* La maggior parte degli editor sono estremamente personalizzabili, e ciascun sviluppatore avrà il suo proprio ambiente di programmazione in grado di soddisfare le sue necessità. Molti consentono agli sviluppatori di creare le loro proprie estensioni.
|
||||
|
||||
#### Popolari Editor ed Estensioni per lo Sviluppo Web
|
||||
|
||||
- [Visual Studio Code](https://code.visualstudio.com/)
|
||||
- [Code Spell Checker](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker)
|
||||
- [Live Share](https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare-pack)
|
||||
- [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)
|
||||
|
||||
### Browser
|
||||
|
||||
Un altro strumento cruciale è il browser. Gli sviluppatori web fanno affidamento sul browser per osservare come il proprio codice viene eseguito nel web, viene anche usato per vedere elementi grafici di una pagina web che sono scritti nell'editor, come HTML.
|
||||
|
||||
Molti browser dispongono di *strumenti per lo sviluppatore* (DevTools) che contengono un insieme di caratteristiche e informazioni per aiutare gli sviluppatori nella raccolta e cattura di importanti approfondimenti in merito alle proprie applicazioni. Ad esempio: se una pagina web ha errori, è talvolta utile sapere dove questi errori sono capitati. DevTools in un browser può essere configurato per catturare queste informazioni.
|
||||
|
||||
#### Popolari Browser e DevTools
|
||||
|
||||
- [Edge](https://docs.microsoft.com/microsoft-edge/devtools-guide-chromium)
|
||||
- [Chrome](https://sviluppatori.google.com/web/tools/chrome-devtools/)
|
||||
- [Firefox](https://sviluppatore.mozilla.org/docs/Tools)
|
||||
|
||||
### Strumenti da Riga di Comando
|
||||
|
||||
Alcuni sviluppatori preferiscono una visione meno grafica per i propri compiti quotidiani e si appoggiano alla riga di comando per completarli. Lo sviluppo del codice richiede un significativo ammontare di digitazione e taluni sviluppatori preferiscono non interrompere il proprio flusso sulla tastiere e usano scorciatoie da tastiera per spostarsi tra finestre del desktop, lavorare su file diversi, e usare strumenti. La maggior parte dei compiti può essere completata con un mouse, ma un vantaggio dell'usare la riga di comando è che molto può essere fatto con essa senza dover passare dalla tastiera al mouse e viceversa. Un altro vantaggio è che è configurabile ed è possibile salvare la propria configurazione, modificarla successivamente, e anche importarla su nuove macchine di sviluppo. Poiché gli ambienti di sviluppo sono così particolari per ciascun sviluppatore, alcuni eviteranno l'uso della riga di comando, altri la utilizzeranno esclusivamente e altri preferiranno mescolare le due tattiche.
|
||||
|
||||
### Popolari Alternative per Riga di Comando
|
||||
|
||||
Le alternative per la riga di comando differiriscono in base al sistema operativo che si sta usando.
|
||||
|
||||
*💻 = preinstallate nel sistema operativo.*
|
||||
|
||||
#### Windows
|
||||
|
||||
- [Powershell](https://docs.microsoft.com/powershell/scripting/overview?view=powershell-7) 💻
|
||||
- [Command Line](https://docs.microsoft.com/windows-server/administration/windows-commands/windows-commands) (also known as CMD) 💻
|
||||
- [Windows Terminal](https://docs.microsoft.com/windows/terminal/)
|
||||
- [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)
|
||||
|
||||
#### Linux
|
||||
|
||||
- [Bash](https://www.gnu.org/software/bash/manual/html_node/index.html) 💻
|
||||
- [KDE Konsole](https://docs.kde.org/trunk5/en/applications/konsole/index.html)
|
||||
- [Powershell](https://docs.microsoft.com/powershell/scripting/install/installing-powershell-core-on-linux?view=powershell-7)
|
||||
|
||||
#### Popolari Strumenti da Riga di Comando
|
||||
|
||||
- [Git](https://git-scm.com/) (💻 nella maggior parte dei sistemi operativi)
|
||||
- [NPM](https://www.npmjs.com/)
|
||||
- [Yarn](https://classic.yarnpkg.com/en/docs/cli/)
|
||||
|
||||
### Documentazione
|
||||
|
||||
Quando uno sviluppatore vuole imparare qualcosa di nuovo, per la maggior parte delle volte farà riferimento alla documentazione per imparare come usarlo. Gli sviluppatori fanno spesso affidamento alla documentazione per essere guidati all'utilizzo corretto degli strumenti e dei linguaggi, oltre a ottenere una più profonda conoscenza del funzionamento.
|
||||
|
||||
#### Popolari Documentazioni sullo Sviluppo Web
|
||||
|
||||
- [Mozilla sviluppatore Network](https://sviluppatore.mozilla.org/docs/Web)
|
||||
- [Frontend Masters](https://frontendmasters.com/learn/)
|
||||
|
||||
✅ Fate qualche ricerca: Ora che sapete le basi per un ambiente di sviluppo web, confrontate e rilevate le differenze rispetto all'ambiente di sviluppo di un web designer.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Sfida
|
||||
|
||||
Confrontate alcuni linguaggi di programmazione. Quali sono i tratti univoci di JavaScript rispetto a Java? E COBOL rispetto a Go?
|
||||
|
||||
## Quiz Post-Lezione
|
||||
[Quiz Post-Lezione](.github/post-lecture-quiz.md)
|
||||
|
||||
## Revisione e Auto Istruzione
|
||||
|
||||
Studiate un poco sui diversi linguaggi di programmazione a disposizione di un programmatore. Cercate di scrivere una riga in un linguaggio, poi rifatelo con altri due. Cosa avete imparato?
|
||||
|
||||
## Compito
|
||||
|
||||
[Leggere la documentazione](assignment.md)
|
||||
@@ -244,4 +244,4 @@ COBOLとGoについては？
|
||||
|
||||
## 課題
|
||||
|
||||
[assignment.md](../assignment.md)
|
||||
[assignment.md](assignment.ja.md)
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
# ドキュメントを読む
|
||||
|
||||
## 説明書
|
||||
|
||||
Web 開発者が必要とする可能性のあるツールは、[クライアントサイドツールの MDN ドキュメント](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Overview)に記載されているものが多くあります。このレッスンでカバーされていないツールを3つ選び、Web 開発者がそれを使う理由を説明し、このカテゴリに該当するツールを検索し、そのドキュメントを共有してください。同じツールの例を MDN ドキュメント上で使用しないでください。
|
||||
|
||||
## ルーブリック
|
||||
|
||||
模範的な例 | 適切な | 改善が必要
|
||||
--- | --- | -- |
|
||||
|Web 開発者がツールを使う理由を説明| 開発者がツールを使用する理由ではなく、どのように使用するかを説明しました。| 開発者がツールを使用する方法や理由については言及していません。 |
|
||||
@@ -149,7 +149,7 @@ Let's say you have a folder locally with some code project and you want to start
|
||||
git push
|
||||
```
|
||||
|
||||
> Tip, You might also want to adopt a `.gitignore` file to prevent files you don't want to track from showing up on GitHub - like that notes file you store in the same folder but has no place on a public repository. You can find templates for `.gitignore` files at [.gitignore templates](github.com/github/gitignore).
|
||||
> Tip, You might also want to adopt a `.gitignore` file to prevent files you don't want to track from showing up on GitHub - like that notes file you store in the same folder but has no place on a public repository. You can find templates for `.gitignore` files at [.gitignore templates](https://github.com/github/gitignore).
|
||||
|
||||
#### Commit messages
|
||||
|
||||
@@ -315,4 +315,4 @@ You'll also find more advanced labs.
|
||||
|
||||
## Assignment
|
||||
|
||||
Complete [the First Week on GitHub training lab](https://lab.github.com/githubtraining/first-week-on-github)
|
||||
Complete [the First Week on GitHub training lab](https://lab.github.com/githubtraining/first-week-on-github)
|
||||
|
||||
@@ -1,19 +0,0 @@
|
||||
*Selesaikan kuis ini dengan mencentang satu jawaban per pertanyaan.*
|
||||
|
||||
1. Tempat untuk membandingkan dan mendiskusikan perbedaan yang diperkenalkan pada cabang dengan review, komentar, tes terintegrasi, dan banyak lagi adalah:
|
||||
|
||||
- [ ] GitHub
|
||||
- [ ] Pull Request (Tarik Permintaan)
|
||||
- [ ] Feature branch (Cabang fitur)
|
||||
|
||||
2. Bagaimana Anda mendapatkan semua komit dari cabang remote (jarak jauh)?
|
||||
|
||||
- [ ] `git fetch`
|
||||
- [ ] `git pull`
|
||||
- [ ] `git commits -r`
|
||||
|
||||
3. Bagaimana Anda beralih ke sebuah cabang (branch)?
|
||||
|
||||
- [ ] `git switch [branch-name]`
|
||||
- [ ] `git checkout [branch-name]`
|
||||
- [ ] `git load [branch-name]`
|
||||
@@ -1,13 +0,0 @@
|
||||
*Selesaikan kuis ini di kelas*
|
||||
|
||||
1. Bagaimana Anda membuat repo Git?
|
||||
|
||||
- [ ] git create
|
||||
- [ ] git start
|
||||
- [ ] git init
|
||||
|
||||
2. Apa fungsi `git add`?
|
||||
|
||||
- [ ] Commit (menyerahkan) kode Anda
|
||||
- [ ] Menambahkan file Anda ke area pementasan (staging area) untuk dilacak
|
||||
- [ ] Menambahkan file Anda ke GitHub
|
||||
@@ -6,7 +6,8 @@ Pelajaran ini mencakup dasar-dasar GitHub, platform untuk menghosting dan mengel
|
||||
> Catatan sketsa oleh [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## Kuis Pra-Kuliah
|
||||
[Kuis pra-kuliah](.github/pre-lecture-quiz.id.md)
|
||||
|
||||
[Kuis pra-kuliah](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/3?loc=id)
|
||||
|
||||
## Pengantar
|
||||
|
||||
@@ -272,7 +273,8 @@ Proyek mungkin juga memiliki diskusi di forum, milis, atau saluran obrolan seper
|
||||
Sandingkan dengan seorang teman untuk mengerjakan kode satu sama lain. Buat proyek secara kolaboratif, buat kode, buat cabang, dan gabungkan perubahan.
|
||||
|
||||
## Kuis Pasca Kuliah
|
||||
[Kuis pasca kuliah](.github/post-lecture-quiz.id.md)
|
||||
|
||||
[Kuis pasca kuliah](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/4?loc=id)
|
||||
|
||||
## Review & Belajar Mandiri
|
||||
|
||||
@@ -288,4 +290,4 @@ Anda juga akan menemukan lab yang lebih canggih.
|
||||
|
||||
## Tugas
|
||||
|
||||
Selesaikan [Minggu Pertama di lab pelatihan GitHub](https://lab.github.com/githubtraining/first-week-on-github)
|
||||
Selesaikan [Minggu Pertama di lab pelatihan GitHub](https://lab.github.com/githubtraining/first-week-on-github)
|
||||
|
||||
@@ -0,0 +1,315 @@
|
||||
# Introduzione a GitHub
|
||||
|
||||
Questa lezione tratta delle basi di GitHub, una piattaforma per ospitare e gestire modifiche al proprio codice.
|
||||
|
||||
|
||||
> Sketchnote by [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## Quiz Pre-lezione
|
||||
[Pre-lecture quiz](../.github/pre-lecture-quiz.md)
|
||||
|
||||
## Introduzione
|
||||
|
||||
In questa lezione tratteremo come:
|
||||
|
||||
- tracciare il lavoro che si fa sulla propria macchina
|
||||
- lavorare con altri su progetti
|
||||
- come contribuire a software open source
|
||||
|
||||
### Prerequisiti
|
||||
|
||||
Prima di iniziare, si dovrebbe verificare se Git è installato. Dal terminale digitare:
|
||||
`git --version`
|
||||
|
||||
Se Git non è installato, [scaricare Git](https://git-scm.com/downloads). Poi impostare il proprio profilo locale Git dal terminale:
|
||||
* `git config --global user.name "il-proprio-nominativo"`
|
||||
* `git config --global user.email "la-propria-email"`
|
||||
|
||||
Per verificare se Git è già configurato si può digitare:
|
||||
`git config --list`
|
||||
|
||||
E' anche necessario un account GitHub, un editor di codice (tipo Visual Studio Code), e sarà necessario aprire il proprio terminale (o prompt di comando).
|
||||
|
||||
Navigare su [github.com](https://github.com/) e creare un account se non se ne dispone già di uno, oppure accedere e compilare il proprio profilo.
|
||||
|
||||
✅ GitHub non è il solo deposito di codice nel mondo, ce ne sono altri, ma GitHub è il più conosciuto.
|
||||
|
||||
### Preparazione
|
||||
|
||||
Servirà sia una cartella con il codice di un progetto sulla propria macchina locale (laptop o PC), e un repository pubblico su GitHub, che servirà come esempio su come contribuire a progetti di altri.
|
||||
|
||||
---
|
||||
|
||||
## Gestione del codice
|
||||
|
||||
Diciamo che si ha una cartella in locale con del codice di un progetto e che si vuole iniziare a tracciarne lo sviluppo usando git - il sistema di controllo di versione. Alcuni paragonano l'uso di git alla scrittura di una lettera d'amore a se stessi nel futuro. Leggendo i messaggi di commit giorni, settimane o mesi più tardi si dovrà essere in grado di ricordare perchè è stata presa una certa decisione, o ripristinare ("rollback") una modifica - questo è, quando si scrivono dei buoni "messaggi di commit".
|
||||
|
||||
### Compito: Creare un repository e inserirvi codice via commit
|
||||
|
||||
1. **Creare un repository su GitHub**. Su GitHub.com, nella scheda repositories, o dalla barra di navigazione in alto a destra, trovare il bottone **new repository**.
|
||||
|
||||
1. Dare un nome al proprio repository (cartella)
|
||||
1. Selezionare **create repository**.
|
||||
|
||||
1. **Navigare verso la propria cartella di lavoro**. Nel proprio terminale, portarsi nella cartella (detta anche directory) che si vuole iniziare a tracciare. Digitare:
|
||||
|
||||
```bash
|
||||
cd [nome della cartella]
|
||||
```
|
||||
|
||||
1. **Inizializzare un repository git**. Nel proprio progetto digitare:
|
||||
|
||||
```bash
|
||||
git init
|
||||
```
|
||||
|
||||
1. **Verifica stato**. Per verificare lo stato del proprio repository digitare:
|
||||
|
||||
```bash
|
||||
git status
|
||||
```
|
||||
|
||||
il risultato potrebbe essere qualcosa tipo:
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
In genere un comando `git status` informa circa quali file sono pronti per essere _salvati_ nel repository o quali modifiche sono state effettuate che si vogliono persistere.
|
||||
|
||||
1. **Aggiungere tutti i file per la tracciatura**
|
||||
Fase nota anche come aggiungere file nell'area di staging.
|
||||
|
||||
```bash
|
||||
git add .
|
||||
```
|
||||
|
||||
Gli argomenti `git add` più `.` indicano che tutti i propri file e modifiche sono selezionati per la tracciatura.
|
||||
|
||||
1. **Aggiungere file selezionati per la tracciatura**
|
||||
|
||||
```bash
|
||||
git add [file o nome cartella]
|
||||
```
|
||||
|
||||
Questo consente di aggiungere file nell'area di staging quando non si vogliono aggiungere tutti in una volta.
|
||||
|
||||
1. **Togliere dall'area di staging tutti i file**
|
||||
|
||||
```bash
|
||||
git reset
|
||||
```
|
||||
|
||||
Questo comando consente di togliere tutti i file dall'area di staging.
|
||||
|
||||
1. **Togliere dall'area di staging uno specifico file**
|
||||
|
||||
```bash
|
||||
git reset [file o nome cartella]
|
||||
```
|
||||
|
||||
Questo comando consente di togliere dall'area di staging uno specifico file che non si vuole includere nel commit successivo.
|
||||
|
||||
1. **Persistere il proprio lavoro**. A questo punto sono stati aggiunti tutti i file alla cosiddetta _area di staging_. Un posto nel quale Git sta tracciando i propri file. Per rendere permanenti le modifiche occorre eseguire un'azione di _commit_ dei file. Per farlo si crea un _commit_ con il comando `git commit`. Un _commit_ rappresenta un punto di salvataggio nella storia del proprio repository. Digitare questo per creare un _commit_:
|
||||
|
||||
```bash
|
||||
git commit -m "primo commit"
|
||||
```
|
||||
|
||||
Questo esegue il commit di tutti i file a suo tempo inclusi, aggiungendo il messaggio 'primo commit'. Per messaggi di commit successivi si vorrà essere più descrittivi nell'esposizione per identificare il tipo di modifiche effettuate.
|
||||
|
||||
1. **Connettere il repository Git locale a GitHub**. Un repository Git va bene sulla propria macchina ma a un certo punto si vuole avere una copia dei propri file da qualche altra parte e anche invitare altre persone a lavorare al proprio progetto. Un gran posto per fare questo è GitHub. Si ricorderà che è stato già creato un repository in GitHub quindi la sola cosa da fare è connettere il repository Git locale con GitHub. Il comando `git remote add` farà proprio questo. Digitare il comando:
|
||||
|
||||
> Nota, prima di digitare il comando portarsi sulla propria pagina del repository su GitHub per trovare l'URL del repository. Dovrà essere usato nel comando seguente. Sostituire `repository_name` con il proprio URL di GitHub e `username` con il proprio nome utente di github.
|
||||
|
||||
```bash
|
||||
git remote add origin https://github.com/username/repository_name.git
|
||||
```
|
||||
|
||||
Questo crea un _remote_, o connessione, chiamata "origin" che punta al repository GitHub precedentemente creato.
|
||||
|
||||
1. **Inviare file locali a GitHub**. Fino ad ora è stata creata una _connessione_ tra il repository locale e quello GitHub. Ora si inviano i file locali a GitHub usando il comando `git push`, in questo modo:
|
||||
|
||||
```bash
|
||||
git push -u origin main
|
||||
```
|
||||
|
||||
Questo invia i propri commit nel ramo "main" di GitHub.
|
||||
|
||||
1. **Aggiungere ulteriori modifiche**. Se si vuole continuare a fare modifiche e inviarle a GitHub occorre usare uno dei tre comandi seguenti:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "digitare qui il messaggio di commit"
|
||||
git push
|
||||
```
|
||||
|
||||
> Suggerimento, Si potrebbe anche utilizzare un file `.gitignore` per evitare che alcuni file che non si vogliono tracciare finiscano su GitHub - come le note che si salvano sulla cartella del progetto ma che non sono adatte in un repository pubblico. Si possono trovare modelli di file `.gitignore` a [modelli .gitignore](github.com/github/gitignore).
|
||||
|
||||
#### Messaggi di commit
|
||||
|
||||
Una grande riga di oggetto per un commit Git completa la seguente frase:
|
||||
Se applicato, questo commit farà ... (qui la vostra riga oggetto)
|
||||
|
||||
Per l'oggetto utilizzare l'imperativo presente: "modifica" non "modificato" o "modifiche"- Come per l'oggetto nel corpo (opzionale) usar4 l'imperativo presente. Il corpo dovrebbe includere il motivo della modifica e il confronto con il precedente comportamento. Si sta spiegando il `perchè`, non il `come`.
|
||||
|
||||
✅ Si prenda qualche minuto per esplorare GitHub. E' possibile scovare un bel messaggio di commit? Se ne puà trovare uno assolutamente minimale? Quali informazioni si pensa che siano le più importanti e utili per un messaggio di commit?
|
||||
|
||||
### Compito: Collaborare
|
||||
|
||||
La ragione principale per inserire cose in GitHub è di fare in modo che si possa collaborare tra sviluppatori.
|
||||
|
||||
## Lavorare su progetti con altri
|
||||
|
||||
Nel proprio repository, portarsi a `Insights > Community` per vedere come il proprio progetto si confronta con gli standard della comunità.
|
||||
|
||||
Ecco alcune cose che possono migliorare il proprio repository GitHub:
|
||||
- **Descrizione**. E' stata aggiunta una descrizione per il proprio progetto?
|
||||
- **README**. E' stato aggiunto un README (leggimi)? GitHub fornisce una traccia per scrivere un [README](https://docs.github.com/articles/about-readmes/).
|
||||
- **Linee guida per contribuire**. Il proprio progetto fornisce [linne guida per contribuire](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/),
|
||||
- **Codice di Condotta**. un [Codice di Condotta](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/),
|
||||
- **Licenza**. Forse la più imporatante, una [licenza](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
|
||||
|
||||
Tutte queste risorse favoriranno la salita a bordo di nuovi elementi nella squadra. Queste sono in genere il tipo di cose che i nuovi contributori cercano anche prima di dare un'occhiata al codice, per scoprire se il progetto è il posto giusto per spendere il loro tempo.
|
||||
|
||||
✅ I file README, sebbene richiedono tempo per prepararli, sono spesso trascurati da manutentori troppo occupati. E' possibile trovare un esempio di uno particolarmente descrittivo? Nota: ci sono alcuni [strumenti per aiutare la creazione di buoni README](https://www.makeareadme.com/) che si potrebbero provare.
|
||||
|
||||
### Compito: Fondere del codice
|
||||
|
||||
La documentazione per la collaborazione aiuta a fare sì che la gente contribuisca al progetto. Spiega che tipo di collaborazione ci si deve attendere e come funziona il processo. I contributori dovranno compiere una serie di passi per poter contribuire a un repository su GitHub:
|
||||
|
||||
1. **Biforcare il repository** Probabilmente si vorrà che la gente possa _biforcare_ il proprio progetto (forking). Questa azione crea una replica di un repository al quale si vuole contribuire sul profilo del contributore su GitHub.
|
||||
1. **Clonare**. Da qui verrà eseguita una azione di clonazione del progetto sulla macchina locale del contributore.
|
||||
1. **Creare un ramo**. Sarà richiesto al contributore di creare un _ramo_ (branch) per il suo lavoro.
|
||||
1. **Concentrare le modifiche del contributore su una area**. Richiedere ai contributori di concentrarsi su una cosa sola alla volta - in questo modo le possibilità che si possa _fondere_ (merge) il lavoro del contributore sono più alte. Se viene scritta la risoluzione di un bug, o viene aggiunta una nuova funzionalità o vengono aggiornati parecchi test - cosa succede se si vuole o si può, solo implementarne 2 su 3 o 1 su 3 di queste modifiche?
|
||||
|
||||
✅ Si immagini una situazione dove i rami sono particolarmente critici per la scrittura e lo sviluppo di buon codice. A quali casi d'uso sono stati individuati?
|
||||
|
||||
> Nota, siate il cambiamento che volete vedere nel mondo, e si creino rami anche per il proprio lavoro. Qualsiasi commit che verrà fatto sarà su rami che si sta attualmente *verificando* (check out). Usare `git status` per vedere su quale ramo ci si trova attualmente.
|
||||
|
||||
Si analizza il flusso di lavoro di un contributore. Si assume che egli abbia già eseguito il _fork_ e _clonato_ il repository in modo che lo stesso sia pronto per lavorarci, sulla sua macchina locale:
|
||||
|
||||
1. **Creare un ramo**. Usare il comando `git branch` per creare un ramo che conterrà le modifiche per le quali si è offerta la collaborazione:
|
||||
|
||||
```bash
|
||||
git branch [branch-name]
|
||||
```
|
||||
|
||||
1. **Passare al ramo di lavoro**. Passare al ramo specificato e aggiornare la directory di lavoro con `git checkout`:
|
||||
|
||||
```bash
|
||||
git checkout [nome ramo]
|
||||
```
|
||||
|
||||
1. **Eseguire il lavoro**. A questo punto si vorranno aggiungere i propri cambiamenti. Non dimenticarsi di dirlo a Git tramite questi comandi:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "le mie modifiche"
|
||||
```
|
||||
|
||||
Assicurarsi che il commit abbia un buon messaggio, a beneficio proprio e del manutentore del repository sul quale si sta collaborando.
|
||||
|
||||
1. **Combinare il proprio lavoro con il ramo `main`**. Una volta terminato il lavoro occorre combinarlo con quello del ramo principale (`main`). Il ramo principale potrebbe avere subito cambiamenti nel mentre quindi ci si deve assicurare di eseguire prima un aggiornamento all'ultima versione con i comandi:
|
||||
|
||||
```bash
|
||||
git checkout main
|
||||
git pull
|
||||
```
|
||||
|
||||
A questo punto occorre assicurarsi che qualsiasi eventuale _conflitto_ (conflict), situazioni dove Git non è in grado di determinare facilmente come _combinare_ le modifiche effettuate nel proprio ramo di lavoro. Eseguire i seguenti comandi:
|
||||
|
||||
```bash
|
||||
git checkout [branch_name]
|
||||
git merge main
|
||||
```
|
||||
|
||||
Questo porterà tutte le modifiche da `main` verso il proprio ramo, augurandosi che si possa poi continuare. In caso contrario VS Code vi può indicare dove Git si _confonde_ e si potranno modificare i file coinvolti per determinare quale contenuto sia il più accurato.
|
||||
|
||||
1. **Inviare il proprio lavoro a GitHub**. Questo significa due cose. Spingere il proprio ramo verso il proprio repository, quindi aprire una PR, Pull Request.
|
||||
|
||||
```bash
|
||||
git push --set-upstream origin [nome-ramo]
|
||||
```
|
||||
|
||||
Il comando qui sopra crea il ramo sulla propria biforcazione del repository.
|
||||
|
||||
1. **Aprire una PR**. Successivamente, si vorrà aprire una Pull Request. Si fa portandosi nel repository biforcato su GitHub. Si vedrà una indicazione su GitHub dove viene chiesto se si vuol creare una nuova PR, cliccando su questa si verrà portati su una interfaccia dove si potrà cambiare il titolo del messaggio di commit e fornire una descrizione più adatta. Ora il manutentore del repository che è stato biforcato vedrà questa PR e _incrociando le dita_ apprezzerà e _fonderà_ (merge) la PR. Ora si avrà contribuito, yay :)
|
||||
|
||||
1. **Pulire**. E' considerata buona pratica effettuare una _pulizia_ dopo il lavoro compiuto. Si vorrà pulire sia il ramo locale che quello spinto su GitHub. Per prima cosa cancellarlo localmente con il comando:
|
||||
|
||||
```bash
|
||||
git branch -d [nome-ramo]
|
||||
```
|
||||
|
||||
Successivamente assicurarsi di andare nella pagina GitHub per del repository biforcato per eliminare il ramo remoto che è stato appena spinto.
|
||||
|
||||
`Pull request` sembra un termine sciocco in quanto in realtà si vogliono portare le proprie modifiche al progetto. Ma il manutentore (proprietario del progetto) o la squadra base deve valutare i cambiamenti dei contributori prima di fonderli con il ramo principale del progetto, quindi in realtà il contributore sta chiedendo una decisione sulle modifiche al manutentore.
|
||||
|
||||
Una pull request è il posto dove confrontare e discutere le differenze introdotte su un ramo con valutazioni, commenti, verifiche integrate e altro. Una buona pull request segue grossolanmente le stesse regole di un messaggio di commit. Si può aggiungere un riferimento al problema nel tracciatore di problemi (issue tracker), quando il proprio lavoro risolve ad esempio un problema. Questo viene fatto usando un `#` seguito dal numero del vostro problema. Ad esempio `#97`.
|
||||
|
||||
🤞Incrociando le dita si spera che tutte le verifiche vengano superate e che il proprietario(i) del progetto voglia incorporare le modifiche all'interno del progetto🤞
|
||||
|
||||
Aggiornare il proprio ramo corrente locale con tutti i nuovi commit per il ramo remoto corrispondente su GitHub:
|
||||
|
||||
`git pull`
|
||||
|
||||
## Come contribuire a progetti open source
|
||||
|
||||
Per prima cosa, trovare un repository - o repo - che interessi su GitHub e per il quale si desideri contribuire con una modifica. Si vorrà copiare il contenuto sulla propria macchina.
|
||||
|
||||
✅ Un buon modo di trovare repository 'adatti per i principianti' è di [cercare il tag 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
|
||||
|
||||
|
||||
|
||||
Ci sono parecchi modi di copiare il codice. Un modo è "clonare" il contenuto del repository, usando HTTPS, SSH, o usando l'interfaccia da riga di comando GitHub CLI.
|
||||
|
||||
Aprire il proprio terminale e clonare il repository così:
|
||||
`git clone https://github.com/URLdelProgetto`
|
||||
|
||||
Per lavorare su un progetto, passare alla corretta cartella:
|
||||
`cd URLdelProgetto`
|
||||
|
||||
Si può anche aprire l'intero progetto usando [Codespaces](https://github.com/features/codespaces), l'editor di codice incorporato di GitHub, oppure un ambiente di sviluppo nel cloud, oppure [GitHub Desktop](https://desktop.github.com/).
|
||||
|
||||
Infine si può scaricare il codice in una cartella compressa.
|
||||
|
||||
### Qualche altra cosa interessante riguardo a GitHub
|
||||
|
||||
E' possibile attribuire una stella, osservare, e/o "biforcare" un qualsiasi progetto pubblico su GitHub. Si possono trovare i propri repository che hanno stelle nel menù a tendina in alto a destra. E' come mettere un segnalibro, ma per il codice.
|
||||
|
||||
I progetti che hanno un tracciatore di problemi, per la maggior parte nella scheda "Issues" di GitHub a meno di indicazioni diverse, è dove la gente discute dei problemi relativi al progetto. E la scheda Pull Requests è dove la gente discute e verifica le modifiche in corso d'opera.
|
||||
|
||||
I progetti potrebbero anche essere discussi nei forum, liste di distribuzione, o canali chat come Slack, Discord o IRC.
|
||||
|
||||
✅ Dare una occhiata al proprio nuovo repository in GitHub e provare alcune cose, come modificare la configurazione, aggiungere informazioni al repository e creare un progetto come un tabellone Kanban. C'è tanto che si può fare!
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Sfida
|
||||
|
||||
Fare coppia con un amico per lavorare al codice dei progetti l'uno dell'altro. Creare un progetto in modo collaborativo, biforcare il codice, craare rami e fondere modifiche.
|
||||
|
||||
## Quiz Post-lezione
|
||||
[Post-lecture quiz](../.github/post-lecture-quiz.md)
|
||||
|
||||
## Revisione e Auto Apprendimento
|
||||
|
||||
Leggene di più al riguardo: [contribuire a software open source](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
|
||||
|
||||
[Git cheatsheet](https://training.github.com/downloads/github-git-cheat-sheet/).
|
||||
|
||||
Esercizio, esercizio, esercizio. GitHub ha ottimi percorsi di apprendimento disponibili via [lab.github.com](https://lab.github.com/):
|
||||
|
||||
- [Prima settimana su GitHub](https://lab.github.com/githubtraining/first-week-on-github)
|
||||
|
||||
Si potranno trovare anche altri laboratori più avanzati.
|
||||
|
||||
## Compito
|
||||
|
||||
Completare [la prima settimana nel laboratorio di apprendimento di GitHub](https://lab.github.com/githubtraining/first-week-on-github)
|
||||
@@ -1,17 +0,0 @@
|
||||
*Selesaikan kuis ini dengan mencentang satu jawaban per pertanyaan.*
|
||||
|
||||
1. Lighthouse hanya memeriksa masalah aksesibilitas
|
||||
|
||||
- [ ] benar
|
||||
- [ ] salah
|
||||
|
||||
2. Palet warna aman membantu orang dengan
|
||||
|
||||
- [ ] buta warna
|
||||
- [ ] gangguan penglihatan
|
||||
- [ ] keduanya di atas
|
||||
|
||||
3. Tautan deskriptif sangat penting untuk situs web yang dapat diakses
|
||||
|
||||
- [ ] benar
|
||||
- [ ] salah
|
||||
@@ -1,17 +0,0 @@
|
||||
*Selesaikan kuis ini di kelas*
|
||||
|
||||
1. Situs web yang dapat diakses dapat diperiksa di alat browser mana
|
||||
|
||||
- [ ] Lighthouse
|
||||
- [ ] Deckhouse
|
||||
- [ ] Cleanhouse
|
||||
|
||||
2. Anda memerlukan pembaca layar fisik untuk menguji aksesibilitas bagi pengguna dengan gangguan penglihatan
|
||||
|
||||
- [ ] benar
|
||||
- [ ] salah
|
||||
|
||||
3. Aksesibilitas hanya penting di situs web pemerintah
|
||||
|
||||
- [ ] benar
|
||||
- [ ] salah
|
||||
@@ -4,7 +4,8 @@
|
||||
> Catatan sketsa oleh [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## Kuis Pra-Kuliah
|
||||
[Kuis pra-kuliah](.github/pre-lecture-quiz.id.md)
|
||||
|
||||
[Kuis pra-kuliah](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/5?loc=id)
|
||||
|
||||
> Kekuatan Web ada dalam universalitasnya. Akses oleh semua orang tanpa memandang disabilitas merupakan aspek penting.
|
||||
>
|
||||
@@ -112,7 +113,7 @@ Sebagai bonus tambahan untuk memastikan situs Anda dapat diakses oleh semua, And
|
||||
Bayangkan halaman berikut:
|
||||
|
||||
| Produk | Deskripsi | Pesan |
|
||||
|--------------|------------------|--------------|
|
||||
| ------------ | ---------------- | ------------ |
|
||||
| Widget | [Deskripsi]('#') | [Pesan]('#') |
|
||||
| Widget super | [Deskripsi]('#') | [Pesan]('#') |
|
||||
|
||||
@@ -208,7 +209,8 @@ Ambil HTML ini dan tulis ulang agar dapat diakses semaksimal mungkin, dengan str
|
||||
```
|
||||
|
||||
## Kuis Pasca Kuliah
|
||||
[Kuis pasca kuliah](.github/post-lecture-quiz.id.md)
|
||||
|
||||
[Kuis pasca kuliah](https://nice-beach-0fe9e9d0f.azurestaticapps.net/quiz/6?loc=id)
|
||||
|
||||
## Review & Belajar Mandiri
|
||||
|
||||
|
||||
@@ -0,0 +1,228 @@
|
||||
# Creare Pagine Web Accessibili
|
||||
|
||||
|
||||
> Sketchnote di [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## Quiz Pre-Lezione
|
||||
[Quiz Pre-Lezione](../.github/pre-lecture-quiz.md)
|
||||
|
||||
> La forza del Web è nella usa universalità. L'accesso garantito a tutti a prescindere dalla disabilità è us aspetto essenziale.
|
||||
>
|
||||
> \- Sir Timothy Berners-Lee, Direttore W3C e Inventore del World Wide Web
|
||||
|
||||
Questa frase evidenzia perfettamente l'importanza di crerare siti web accessibili. Una applicazione che non può essere acceduta da tutti diventa per definizione esclusivista. Come sviluppatori web si dovrebbe sempre tenere a mente l'accessibilità. Focalizzandosi su questo fin dal principio si sarà sulla buona strada per garantire a chiunque l'accesso alle pagine che si sono create. In questa lezione, si apprenderanno gli strumenti che possono aiutare a rendere le proprie risorse web accessibili e che siano costruite con in mente l'accessibilità.
|
||||
|
||||
## Strumenti da usare
|
||||
|
||||
### Lettori di schermo
|
||||
|
||||
Uno dei più noti strumenti di accessibilità sono i lettori di schermo (screen reader)
|
||||
|
||||
I [lettori di schermo](https://www.wikiwand.com/it/Screen_reader) sono strumenti client comunemente usati per persone con menomazioni visive. Poiché dedichiamo tempo a garantire che un browser trasmetta correttamente le informazioni che desideriamo condividere, dobbiamo anche assicurarci che uno screen reader faccia lo stesso.
|
||||
|
||||
Nella sua forma più elementare, uno screen reader leggerà una pagina dall'alto verso il basso in modo udibile. Se una pagina è tutta testo, il lettore trasmetterà le informazioni in modo simile a un browser. Naturalmente, le pagine web sono raramente puramente testuali; contengono collegamenti, grafica, colore e altri componenti visivi. È necessario prestare attenzione per garantire che queste informazioni vengano lette correttamente da uno screen reader.
|
||||
|
||||
Ogni sviluppatore web dovrebbe acquisire familiarità con uno screen reader. Come evidenziato sopra, è il client che gli utenti dello sviluppatore utilizzeranno. Allo stesso modo in cui si ha familiarità con il funzionamento di un browser, si dovrebbe imparare come funziona uno screen reader. Fortunatamente, gli screen reader sono integrati nella maggior parte dei sistemi operativi.
|
||||
|
||||
Alcuni browser hanno anche strumenti incorporati ed estensioni che possono leggere il testo ad alta voce o persino fornire alcune funzionalità di navigazione di base, come [questi strumenti orientati all'accessibilità del browser Edge](https://support.microsoft.com/en-us/help/4000734/microsoft-edge-accessibility-features) . Anche questi sono importanti strumenti di accessibilità, ma funzionano in modo molto diverso dagli screen reader e non dovrebbero essere scambiati per strumenti di test per uno screen reader.
|
||||
|
||||
✅ Provare un lettore di schermo e un lettore di testo del browser. In Windows, l'[Assistente vocale](https://support.microsoft.com/en-us/windows/complete-guide-to-narrator-e4397a0d-ef4f-b386-d8ae-c172f109bdb1) (Narrator) è incluso per impostazione predefinita e anche [JAWS](https://webaim.org/articles/jaws/) e [NVDA](https://www.nvaccess.org/about-nvda/) possono essere installati Su macOS e iOS, [VoiceOver](https://support.apple.com/guide/voiceover/welcome/10) è installato per impostazione predefinita.
|
||||
|
||||
### Zoom
|
||||
|
||||
Un altro strumento comunemente utilizzato dalle persone con problemi di vista è lo zoom. Il tipo più semplice di zoom è lo zoom statico, controllato tramite `Control + segno più (+)` o diminuendo la risoluzione dello schermo. Questo tipo di zoom provoca il ridimensionamento dell'intera pagina, quindi l'utilizzo [di una progettazione responsive](https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Responsive_Design) della pagina è importante per fornire una buona esperienza utente a livelli di zoom aumentati.
|
||||
|
||||
Un altro tipo di zoom si basa su un software specializzato per ingrandire un'area dello schermo e fare una panoramica, proprio come usare una vera lente di ingrandimento. Su Windows, [Magnifier](https://support.microsoft.com/en-us/windows/use-magnifier-to-make-things-on-the-screen-easier-to-see-414948ba-8b1c-d3bd-8615-0e5e32204198) è integrato e [ZoomText](https://www.freedomscientific.com/training/zoomtext/getting-started/) è un software di ingrandimento di terze parti con più funzionalità e una base di utenti più ampia. Sia macOS che iOS hanno un software di ingrandimento integrato chiamato [Zoom](https://www.apple.com/accessibility/mac/vision/).
|
||||
|
||||
### Verificatori di contrasto
|
||||
|
||||
I colori sui siti web devono essere scelti con cura per rispondere alle esigenze degli utenti daltonici o delle persone che hanno difficoltà a vedere i colori a basso contrasto.
|
||||
|
||||
✅ Provare un sito web che piace usare per l'utilizzo del colore con un'estensione del browser come [il controllo del colore WCAG](https://microsoftedge.microsoft.com/addons/detail/wcag-color-contrast-check/idahaggnlnekelhgplklhfpchbfdmkjp?hl=en-US). Cosa si è appreso?
|
||||
|
||||
### Lo strumento Faro (Lighthouse)
|
||||
|
||||
Nell'area degli strumenti per sviluppatori del browser, si troverà lo strumento Lighthouse. Questo strumento è importante per ottenere una prima visione dell'accessibilità (così come altre analisi) di un sito web. Sebbene sia importante non fare affidamento esclusivamente su Lighthouse, un punteggio del 100% è molto utile come riferimento.
|
||||
|
||||
✅ Trovare Lighthouse nel pannello degli strumenti per sviluppatori del proprio browser ed eseguire un'analisi su qualsiasi sito. Cosa si è scoperto?
|
||||
|
||||
## Progettare per l'accessibilità
|
||||
|
||||
L'accessibilità è un argomento relativamente ampio. A supporto, sono disponibili numerose risorse.
|
||||
|
||||
- [Accessibile U - Università del Minnesota](https://accessibility.umn.edu/your-role/web-developers)
|
||||
|
||||
Sebbene non si sarà in grado di coprire ogni aspetto della creazione di siti accessibili, di seguito sono riportati alcuni dei principi fondamentali che si vorranno implementare. Progettare una pagina accessibile dall'inizio è **sempre** più facile che tornare a una pagina esistente per renderla accessibile.
|
||||
|
||||
## Buoni principi di visualizzazione
|
||||
|
||||
### Tavolozze di colori sicuri
|
||||
|
||||
Le persone vedono il mondo in modi diversi, e questo include i colori. Quando si seleziona una combinazione di colori per il proprio sito, ci si dovrebbe assicurare che sia accessibile a tutti. Un ottimo [strumento per generare tavolozze di colori è Color Safe](http://colorsafe.co/).
|
||||
|
||||
✅ Identificare un sito web che è molto problematico nel suo uso del colore. Perché?
|
||||
|
||||
### Usa l'HTML corretto
|
||||
|
||||
Con CSS e JavaScript è possibile far sembrare qualunque elemento come un qualsiasi tipo di controllo. `<span>` potrebbe essere usato per creare un `<button>`, e `<b>` potrebbe diventare un collegamento ipertestuale. Sebbene questo possa essere considerato più facile da definire, non trasmette nulla a uno screen reader. Occorre usare l'HTML appropriato quando si creano i controlli su una pagina. Se si vuole un collegamento ipertestuale usare `<a>`. L'utilizzo dell'HTML corretto per il controllo corretto è chiamato fare uso dell'HTML semantico.
|
||||
|
||||
✅ Portarsi su qualsiasi sito web e controllare se i progettisti e gli sviluppatori stanno usando l'HTML correttamente. Si riesce a trovare un pulsante che dovrebbe essere un collegamento? Suggerimento: fare clic con il tasto destro e scegliere "Visualizza sorgente pagina" nel browser per esaminare il codice relativo.
|
||||
|
||||
### Creare una gerarchia descrittiva delle intestazioni
|
||||
|
||||
Gli utenti di screen reader [fanno molto affidamento sui titoli](https://webaim.org/projects/screenreadersurvey8/#finding) per trovare informazioni e navigare in una pagina. La scrittura di contenuto di intestazione descrittiva e l'utilizzo di tag di intestazione semantici sono importanti per creare un sito facilmente navigabile per gli utenti di lettori di schermo.
|
||||
|
||||
### Usare buoni indizi visivi
|
||||
|
||||
CSS offre il controllo completo sull'aspetto di qualsiasi elemento in una pagina. È possibile creare caselle di testo senza un contorno o collegamenti ipertestuali senza una sottolineatura. Sfortunatamente rimuovere questi indizi può rendere più difficile per qualcuno che dipende da loro essere in grado di riconoscere il tipo di controllo.
|
||||
|
||||
## L'importanza del testo del collegamento
|
||||
|
||||
I collegamenti ipertestuali sono fondamentali per la navigazione sul Web. Di conseguenza, assicurarsi che uno screen reader possa leggere correttamente i collegamenti consente a tutti gli utenti di navigare nel proprio sito.
|
||||
|
||||
### Lettori di schermo e collegamenti
|
||||
|
||||
Come ci si potrebbe aspettare, gli screen reader leggono il testo del collegamento nello stesso modo in cui leggono qualsiasi altro testo nella pagina. Tenedo presente questo, il testo mostrato di seguito potrebbe sembrare perfettamente accettabile.
|
||||
|
||||
> Il pinguino minore, a volte noto come il pinguino delle fate, è il più piccolo pinguino del mondo. [Fare clic qui](https://en.wikipedia.org/wiki/Little_penguin) per ulteriori informazioni.
|
||||
|
||||
> Il Il pinguino minore, a volte noto come il pinguino delle fate, è il più piccolo pinguino del mondo. Visitare https://en.wikipedia.org/wiki/Little_penguin per ulteriori informazioni.
|
||||
|
||||
> **NOTA** Come si leggerà di seguito, non si dovrebbero **mai** creare collegamenti che assomigliano all'esempio precedente
|
||||
|
||||
Si ricordi che gli screen reader sono un'interfaccia diversa dai browser con un diverso insieme di funzionalità.
|
||||
|
||||
### Il problema con l'utilizzo dell'URL
|
||||
|
||||
I lettori di schermo leggono il testo. Se nel testo viene visualizzato un URL, lo screen reader leggerà l'URL. In generale, l'URL non trasmette informazioni significative e può sembrare al suono fastidioso. Si potrebbe averlo riscontrato se il proprio telefono ha mai letto in modo udibile un messaggio di testo con un URL.
|
||||
|
||||
### Il problema con "clicca qui"
|
||||
|
||||
I lettori di schermo hanno anche la capacità di leggere solo i collegamenti ipertestuali su una pagina, molto nello stesso modo in cui una persona vedente scorrerebbe una pagina per cercare collegamenti. Se il testo del link è sempre "clicca qui", tutto ciò che l'utente sentirà sarà "clicca qui, clicca qui, clicca qui, clicca qui, clicca qui, ..." Tutti i collegamenti sono ora indistinguibili l'uno dall'altro.
|
||||
|
||||
### Buon testo del collegamento
|
||||
|
||||
Un buon testo del collegamento descrive brevemente cosa c'è dall'altra parte del collegamento. Nell'esempio sopra che parla di piccoli pinguini, il collegamento è alla pagina di Wikipedia sulla specie. La frase *piccoli pinguini* renderebbe il testo del collegamento perfetto in quanto chiarisce ciò che qualcuno imparerà se fa clic sul collegamento: piccoli pinguini.
|
||||
|
||||
> Il [pinguino minore](https://www.wikiwand.com/it/Eudyptula_minor), a volte noto come il pinguino delle fate, è il più piccolo pinguino del mondo.
|
||||
|
||||
✅ Navigare sul Web per alcuni minuti per trovare pagine che utilizzano oscure strategie di collegamento. Confrontarle con altri siti con collegamenti migliori. Cosa si è appreso?
|
||||
|
||||
#### Note sui motori di ricerca
|
||||
|
||||
Come bonus aggiuntivo per garantire che il proprio sito sia accessibile a tutti, si dovranno aiutare anche i motori di ricerca a navigare nel sito. I motori di ricerca utilizzano il testo del collegamento per apprendere gli argomenti delle pagine. Quindi usare un buon testo per i link aiuta tutti!
|
||||
|
||||
### ARIA
|
||||
|
||||
Si Immagini la pagina seguente:
|
||||
|
||||
| Prodotto | Descrizione | Ordine |
|
||||
| ------------ | ------------------ | ------------ |
|
||||
| Widget | [Descrizione]('#') | [Ordine]('#') |
|
||||
| DMX Super Widget | [Descrizione]('#') | [Ordine]('#') |
|
||||
|
||||
In questo esempio, la duplicazione del testo della descrizione e dell'ordine ha senso per qualcuno che utilizza un browser. Tuttavia, qualcuno che utilizza uno screen reader ascolterebbe solo le parole *descrizione* e *ordine* ripetute senza contesto.
|
||||
|
||||
Per supportare questi tipi di scenari, HTML supporta una serie di attributi noti come [ARIA (Accessible Rich Internet Applications)](https://developer.mozilla.org/docs/Web/Accessibility/ARIA). Questi attributi consentono di fornire informazioni aggiuntive agli screen reader.
|
||||
|
||||
> **NOTA**: come molti aspetti dell'HTML, il supporto del browser e dello screen reader può variare. Tuttavia, la maggior parte dei client principali supporta gli attributi ARIA.
|
||||
|
||||
E' possibile utilizzare `aria-label` per descrivere il collegamento quando il formato della pagina non lo consente. La descrizione del widget potrebbe essere impostata come
|
||||
|
||||
```html
|
||||
<a href="#" aria-label="Widget description">description</a>
|
||||
```
|
||||
|
||||
✅ In generale, l'uso del markup semantico come descritto sopra sostituisce l'uso di ARIA, ma a volte non esiste un equivalente semantico per diversi widget HTML. Un buon esempio è una struttura ad albero. Non esiste un equivalente HTML per una struttura ad albero, quindi si identifica il generico `<div>` per questo elemento con un ruolo e valori aria appropriati. La [documentazione MDN su ARIA](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA) contiene ulteriori utili informazioni.
|
||||
|
||||
```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>
|
||||
```
|
||||
|
||||
## Immagini
|
||||
|
||||
Inutile dire che gli screen reader non sono in grado di leggere automaticamente il contenuto di un'immagine. Assicurarsi che le immagini siano accessibili non richiede molto lavoro: è ciò di cui tratta l'attributo `alt` . Tutte le immagini significative dovrebbero avere un `alt` per descrivere cosa sono. Le immagini che sono puramente decorative dovrebbero avere il loro attributo `alt` impostato su una stringa vuota: `alt = ""`. Ciò impedisce ai lettori di schermo di annunciare inutilmente l'immagine decorativa.
|
||||
|
||||
✅ Come ci si potrebbe aspettare, anche i motori di ricerca non sono in grado di capire cosa c'è in un'immagine. Anch'essi usano il testo alternativo. Quindi, ancora una volta, assicurandosi che la propria pagina sia accessibile fornisce bonus aggiuntivi!
|
||||
|
||||
## La tastiera
|
||||
|
||||
Alcuni utenti non sono in grado di utilizzare un mouse o un trackpad, affidandosi invece alle interazioni della tastiera per passare da un elemento all'altro. È importante che il proprio sito web presenti i contenuti in ordine logico in modo che un utente usando la tastiera possa accedere a ogni elemento interattivo mentre si sposta nel flusso di un documento. Se si creano le proprie pagine web con markup semantico e si utilizza CSS per definire lo stile del layout visivo, il proprio sito dovrebbe essere navigabile da tastiera, ma è importante testare manualmente questo aspetto. Per saperne di più su ulteriori informazioni sulle [strategie di navigazione da tastiera](https://webaim.org/techniques/keyboard/).
|
||||
|
||||
✅ Andare su qualsiasi sito web e provare a navigarlo utilizzando solo la tastiera. Cos'è che funziona e cos'è che non funziona? Perché?
|
||||
|
||||
## Riepilogo
|
||||
|
||||
Un Web accessibile ad alcuni non è un vero "world-wide web". Il modo migliore per garantire che i siti che si creano siano accessibili è incorporare le migliori pratiche di accessibilità sin dall'inizio. Sebbene siano necessari passaggi aggiuntivi, incorporare queste abilità nel flusso di lavoro ora significa che tutte le pagine che si creeranno saranno accessibili.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Sfida
|
||||
|
||||
Prendere questo HTML e riscriverlo per essere il più accessibile possibile, date le strategie che sono state apprese.
|
||||
|
||||
```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">The World's Premier Turtle Fan Club</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">"I like turtles"</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="https://en.wikipedia.org/wiki/Turtle">Basic Turtle Info</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="https://en.wikipedia.org/wiki/Turtles_(chocolate)">Chocolate Turtles</a></p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="main-content">
|
||||
<div>
|
||||
<p class="page-title">Welcome to Turtle Ipsum.
|
||||
<a href="">Click here</a> to learn more.
|
||||
</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">Sign up for turtle news</span>
|
||||
</div><div class="footer-section">
|
||||
<p class="nav-header footer-title">
|
||||
Internal Pages
|
||||
</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">Semantic Example</a></p>
|
||||
</div>
|
||||
</div>
|
||||
<p class="footer-copyright">© 2016 Instrument</span>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
## Quiz post-lezione
|
||||
[Quiz post-lezione](../.github/post-lecture-quiz.md)
|
||||
|
||||
## Revisione e auto apprendimento
|
||||
|
||||
Molti governi hanno leggi riguardanti i requisiti di accessibilità. Consultare le leggi sull'accessibilità del proprio paese d'origine. Cosa è coperto e cosa no? Un esempio è [questo sito web del governo inglese](https://accessibility.blog.gov.uk/).
|
||||
|
||||
## Assegnazione
|
||||
|
||||
[Analizzare un sito web non accessibile](assignment.md)
|
||||
|
||||
Crediti: [Turtle Ipsum](https://github.com/Instrument/semantic-html-sample) da Instrument
|
||||
@@ -0,0 +1,229 @@
|
||||
# アクセシブルな Web ページの作成
|
||||
|
||||
|
||||
> Sketchnote by [Tomomi Imura](https://twitter.com/girlie_mac)
|
||||
|
||||
## レクチャー前クイズ
|
||||
[レクチャー前クイズ](.github/pre-lecture-quiz.md)
|
||||
|
||||
> Web の力は、その普遍性にあります。障害の有無に関わらず、誰もがアクセスできることが重要です。
|
||||
>
|
||||
> \- Sir Timothy Berners-Lee, W3C 理事、World Wide Web の発明者
|
||||
|
||||
この引用は、アクセシブルな Web サイトを作成することの重要性を完璧に強調しています。すべての人がアクセスできないアプリケーションは、定義上、排除的なものです。Web 開発者として、私たちは常にアクセシビリティを念頭に置くべきです。最初からこのことに焦点を当てることで、あなたが作成したページに誰もがアクセスできるようにすることができるようになります。このレッスンでは、Web 資産がアクセシブルであることを確実にするのに役立つツールと、アクセシビリティを念頭に置いて構築する方法について学びます。
|
||||
|
||||
## 使用するツール
|
||||
|
||||
### スクリーンリーダー
|
||||
|
||||
よく知られているアクセシビリティツールの一つにスクリーンリーダーがあります。
|
||||
|
||||
[スクリーンリーダー](https://ja.wikipedia.org/wiki/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%83%AA%E3%83%BC%E3%83%80%E3%83%BC)は、視覚障害のある方のために一般的に使用されているクライアントです。ブラウザが共有したい情報を適切に伝えることに時間を費やしているので、スクリーンリーダーも同じように情報を伝えるようにしなければなりません。
|
||||
|
||||
スクリーンリーダーは、最も基本的には、ページを上から下まで音声で読み上げます。あなたのページがすべてテキストである場合、リーダーはブラウザと同様の方法で情報を伝えます。もちろん、ウェブページが純粋なテキストであることはほとんどなく、リンク、グラフィック、カラー、その他の視覚的な要素が含まれます。これらの情報がスクリーンリーダーに正しく読まれるように注意を払わなければなりません。
|
||||
|
||||
すべてのウェブ開発者は、スクリーンリーダーに慣れる必要があります。上で強調したように、ユーザーが利用するのはクライアントです。ブラウザの操作方法を熟知しているのと同じように、スクリーンリーダーの操作方法を学ぶべきです。幸いなことに、スクリーンリーダーはほとんどのオペレーティングシステムに組み込まれています。
|
||||
|
||||
ブラウザの中には、テキストを音読したり、基本的なナビゲーション機能を提供したりするツールや拡張機能を内蔵しているものもありますが、[これらはアクセシビリティに焦点を当てたEdgeブラウザツール](https://support.microsoft.com/ja-jp/microsoft-edge/microsoft-edge-%E3%81%AE%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B7%E3%83%93%E3%83%AA%E3%83%86%E3%82%A3%E6%A9%9F%E8%83%BD-4c696192-338e-9465-b2cd-bd9b698ad19a)のようなものです。これらも重要なアクセシビリティツールですが、スクリーンリーダーとは機能が大きく異なるため、スクリーンリーダーのテストツールと勘違いしてはいけません。
|
||||
|
||||
✅ スクリーンリーダーやブラウザのテキストリーダーを試してみましょう。Windows ではデフォルトで [Narrator](https://support.microsoft.com/ja-jp/windows/%E3%83%8A%E3%83%AC%E3%83%BC%E3%82%BF%E3%83%BC%E3%81%AE%E8%A9%B3%E7%B4%B0%E3%81%AA%E3%82%AC%E3%82%A4%E3%83%89-e4397a0d-ef4f-b386-d8ae-c172f109bdb1) が搭載されており、[JAWS](https://webaim.org/articles/jaws/) や [NVDA](https://www.nvaccess.org/about-nvda/) もインストールできます。macOS と iOS では、[VoiceOver](https://support.apple.com/guide/voiceover/welcome/10) がデフォルトでインストールされています。
|
||||
|
||||
### ズーム
|
||||
|
||||
視覚障害のある人がよく使うもう一つのツールは、ズームです。ズームの最も基本的なタイプは静的ズームで、`コントロール + プラス記号 (+)` で制御するか、画面の解像度を下げることで制御します。このタイプのズームではページ全体のサイズが変更されるため、[レスポンシブデザイン](https://developer.mozilla.org/ja/docs/Learn/CSS/CSS_layout/Responsive_Design)を使用することは、ズームレベルを上げても良いユーザー体験を提供するために重要です。
|
||||
|
||||
もう一つのタイプのズームは、特殊なソフトウェアを使用して、実際の虫眼鏡を使用するのと同じように、画面のある領域を拡大してパンすることを目的としています。Windows では、[Magnifier](https://support.microsoft.com/ja-jp/windows/%E7%94%BB%E9%9D%A2%E4%B8%8A%E3%81%AE%E9%A0%85%E7%9B%AE%E3%82%92%E8%A6%8B%E3%82%84%E3%81%99%E3%81%8F%E3%81%99%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AB-%E6%8B%A1%E5%A4%A7%E9%8F%A1%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%99%E3%82%8B-414948ba-8b1c-d3bd-8615-0e5e32204198) が内蔵されており、[ZoomText](https://www.freedomscientific.com/training/zoomtext/getting-started/) は、より多くの機能を持ち、より多くのユーザーベースを持つサードパーティ製の拡大表示ソフトウェアです。macOS と iOS の両方には、[Zoom](https://www.apple.com/accessibility/mac/vision/) と呼ばれる拡大鏡ソフトが内蔵されています。
|
||||
|
||||
### コントラストチェッカー
|
||||
|
||||
Webサイトの色は、色覚障害者やコントラストの低い色が見えにくい人のニーズに応えるために、慎重に選ぶ必要があります。
|
||||
|
||||
✅ [WCAG のカラーチェッカー](https://microsoftedge.microsoft.com/addons/detail/wcag-color-contrast-check/idahaggnlnekelhgplklhfpchbfdmkjp?hl=ja-JP)などのブラウザ拡張機能を使って、色使いを楽しむ Web サイトをテストしてみましょう。何がわかりますか？
|
||||
|
||||
### Lighthouse
|
||||
|
||||
ブラウザの開発者ツールエリアには、Lighthouse ツールがあります。このツールは、Web サイトのアクセシビリティ (他の分析と同様に) を最初に見るために重要です。Lighthouse だけに頼らないことが重要ですが、100% のスコアはベースラインとして非常に役立ちます。
|
||||
|
||||
✅ ブラウザの開発者ツールパネルで Lighthouse を見つけて、任意のサイトで分析を実行してください。何を発見しましたか？
|
||||
|
||||
## アクセシビリティを考慮した設計
|
||||
|
||||
アクセシビリティは比較的大きなテーマです。あなたを助けるために、多くのリソースが用意されています。
|
||||
|
||||
- [Accessible U - University of Minnesota](https://accessibility.umn.edu/your-role/web-developers)
|
||||
|
||||
アクセシブルなサイトを作成するためのすべての側面をカバーすることはできませんが、以下は、あなたが実装したいと思う中核的な原則のいくつかです。アクセシブルなページを最初からデザインすることは、既存のページに戻ってアクセシブルにするよりも**常に**簡単です。
|
||||
|
||||
## 良い表示の原則
|
||||
|
||||
### カラーセーフパレット
|
||||
|
||||
人はさまざまな方法で世界を見ていますが、これには色も含まれます。サイトの配色を選択する際には、誰もがアクセスできるようにする必要があります。[カラーパレットを生成するための素晴らしいツールの1つが Color Safe ](http://colorsafe.co/)です。
|
||||
|
||||
✅ 色の使用に非常に問題のある Web サイトを特定してください。なぜですか？
|
||||
|
||||
### 正しい HTML を使用する
|
||||
|
||||
CSS と JavaScript を使えば、あらゆる要素をあらゆるタイプのコントロールのように見せることができます。`<span>` を使って `<button>` を作成したり、`<b>` をハイパーリンクにしたりすることができます。この方がスタイルを整えるのは簡単だと思われるかもしれませんが、スクリーンリーダーには何も伝わりません。ページ上でコントロールを作成する際には、適切な HTML を使用してください。ハイパーリンクが必要な場合は、`<a>` を使用します。適切なコントロールに適切なHTML を使うことをセマンティック HTML の利用といいます。
|
||||
|
||||
✅ 任意の Web サイトに行って、デザイナーや開発者が HTML を適切に使用しているかどうかを確認してください。リンクであるはずのボタンを見つけることができますか？ヒント: 右クリックして、ブラウザで「View Page Source」を選択して、基礎となるコードを見てみましょう。
|
||||
|
||||
### 記述的な見出しの階層を作成する
|
||||
|
||||
スクリーンリーダーのユーザーは、情報を見つけたり、ページをナビゲートしたりするために、[見出しに大きく依存しています](https://webaim.org/projects/screenreadersurvey8/#finding)。記述的な見出しコンテンツを書き、意味的な見出しタグを使用することは、スクリーンリーダーのユーザーがナビゲートしやすいサイトを作成するために重要です。
|
||||
|
||||
### 視覚的な手がかりを上手に使う
|
||||
|
||||
CSS は、ページ上のあらゆる要素の外観を完全に制御することができます。アウトラインのないテキストボックスやアンダーラインのないハイパーリンクを作成することができます。残念ながら、これらの手がかりを削除すると、それらに依存している人がコントロールの種類を認識することが難しくなる可能性があります。
|
||||
|
||||
## リンクテキストの重要性
|
||||
|
||||
ハイパーリンクは、ウェブをナビゲートするための核となるものです。その結果、スクリーンリーダーがリンクを適切に読めるようにすることで、すべてのユーザーがサイトをナビゲートできるようになります。
|
||||
|
||||
### スクリーンリーダーとリンク
|
||||
|
||||
ご想像の通り、スクリーンリーダーはリンクテキストをページ上の他のテキストと同じように読みます。このことを念頭に置いて、以下に示すテキストは完全に許容できると感じるかもしれません。
|
||||
|
||||
> 妖精ペンギンと呼ばれることもあるコガタペンギンは、世界最小のペンギンです。[詳しくはこちら](https://en.wikipedia.org/wiki/Little_penguin) をご覧ください。
|
||||
|
||||
> 妖精ペンギンと呼ばれることもあるリトルペンギンは、世界最小のペンギンです。詳しくは https://ja.wikipedia.org/wiki/%E3%82%B3%E3%82%AC%E3%82%BF%E3%83%9A%E3%83%B3%E3%82%AE%E3%83%B3 をご覧ください。
|
||||
|
||||
> **注** 今から読むように、上記のようなリンクは絶対に作っては**いけません**。
|
||||
|
||||
スクリーンリーダーは、ブラウザとは異なる機能のセットを持つ別のインターフェイスであることを覚えておいてください。
|
||||
|
||||
### URL を使用する場合の問題点
|
||||
|
||||
スクリーンリーダーはテキストを読みます。本文中に URL が表示されている場合、スクリーンリーダーはその URL を読みます。一般的に、URL は意味のある情報を伝えず、迷惑に聞こえることがあります。あなたの携帯電話が URL 付きのテキストメッセージを音声で読んだことがある場合は、このような経験をしたことがあるかもしれません。
|
||||
|
||||
### "こちらをクリック" の問題点
|
||||
|
||||
スクリーンリーダーは、目の不自由な人がページをスキャンしてリンクを探すのと同じように、ページ上のハイパーリンクだけを読む機能も持っています。リンクテキストが常に「ここをクリックしてください」となっている場合、ユーザーは「ここをクリックしてください、ここをクリックしてください、ここをクリックしてください、ここをクリックしてください、ここをクリックしてください、ここをクリックしてください、ここをクリックしてください、ここをクリックしてください、...」としか聞こえません。すべてのリンクは互いに区別がつかなくなりました。
|
||||
|
||||
### 良いリンクテキスト
|
||||
|
||||
良いリンクの文章は、リンクの向こう側に何があるのかを簡潔に説明します。上記の例では、コガタペンギンについて話していますが、リンク先はその種についての Wikipedia のページになっています。*コガタペンギン* というフレーズは、リンクをクリックした場合に何を学ぶのかが明確になるので、完璧なリンクテキストになります。
|
||||
|
||||
> 妖精ペンギンとして知られることもある[コガタペンギン](https://ja.wikipedia.org/wiki/%E3%82%B3%E3%82%AC%E3%82%BF%E3%83%9A%E3%83%B3%E3%82%AE%E3%83%B3)は、世界で最も小さいペンギンです。
|
||||
|
||||
✅ 数分間 Web サーフィンをして、不明瞭なリンク戦略を使用しているページを見つけましょう。他の、より良いリンクを貼られているサイトと比較してみてください。あなたは何を学びますか？
|
||||
|
||||
#### 検索エンジンの注意事項
|
||||
|
||||
あなたのサイトが誰でもアクセスできるようにすることで、検索エンジンがあなたのサイトをナビゲートするのにも役立ちます。検索エンジンは、ページのトピックを学習するためにリンクテキストを使用します。ですから、良いリンクテキストを使用することは誰にでも役立ちます。
|
||||
|
||||
### ARIA
|
||||
|
||||
次のページを想像してみてください。
|
||||
|
||||
| Product | Description | Order |
|
||||
| ------------ | ------------------ | ------------ |
|
||||
| Widget | [Description]('#') | [Order]('#') |
|
||||
| Super widget | [Description]('#') | [Order]('#') |
|
||||
|
||||
この例では、description と order のテキストを複製しても、ブラウザを使っている人にとっては意味があります。しかし、スクリーン・リーダーを使っている人には、文脈なしに繰り返される *description* と *order* という単語しか聞こえません。
|
||||
|
||||
これらのタイプのシナリオをサポートするために、HTML は[アクセシブル・リッチ・インターネット・アプリケーション (ARIA)](https://developer.mozilla.org/ja/docs/Web/Accessibility/ARIA)として知られている一連の属性をサポートしています。これらの属性により、スクリーンリーダーに追加の情報を提供することができます。
|
||||
|
||||
> **NOTE**: HTML の多くの側面と同様に、ブラウザやスクリーンリーダーのサポートは異なるかもしれません。しかし、ほとんどのメインラインのクライアントは ARIA 属性をサポートしています。
|
||||
|
||||
ページのフォーマットでリンクを記述できない場合、`aria-label` を使ってリンクを記述することができます。ウィジェットの説明は
|
||||
|
||||
``` html
|
||||
<a href="#" aria-label="Widget description">description</a>
|
||||
```
|
||||
|
||||
✅ 一般的には、上記のようにセマンティックマークアップを使用することで ARIA の使用が優先されますが、様々な HTML ウィジェットにはセマンティックに相当するものが存在しないことがあります。良い例がツリーです。ツリーには HTML と同等のものがないので、適切なロールとアリアの値でこの要素の一般的な `<div>` を識別します。[ARIA に関する MDN のドキュメント](https://developer.mozilla.org/ja/docs/Web/Accessibility/ARIA)には、より有用な情報が含まれています。
|
||||
|
||||
```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>
|
||||
```
|
||||
|
||||
## 画像
|
||||
|
||||
言うまでもなく、スクリーンリーダーは画像の中にあるものを自動的に読み取ることができません。画像を確実にアクセスできるようにするには、それほどの労力は必要ありません - それが `alt` 属性のすべてです。意味のある画像はすべて、その画像が何であるかを説明するための `alt` を持つべきです。
|
||||
純粋に装飾的な画像は `alt` 属性に空の文字列を設定しなければなりません。`alt=""`です。これにより、スクリーンリーダが装飾的な画像を不必要に知らせることを防ぐことができます。
|
||||
|
||||
✅ さすがに検索エンジンも画像の中身を理解することができません。彼らもまた、alt テキストを使用しています。ですから、もう一度言いますが、あなたのページがアクセス可能であることを確認することは、追加のボーナスを提供します。
|
||||
|
||||
## キーボード
|
||||
|
||||
マウスやトラックパッドを使用できないユーザーの中には、1つの要素から次の要素へとタブを移動するためにキーボードのインタラクションに頼っている人もいます。キーボードを使用するユーザーがドキュメントの下に移動しながら各インタラクティブ要素にアクセスできるように、Web サイトのコンテンツを論理的な順序で表示することが重要です。Web ページをセマンティック マークアップで構築し、CSS を使用して視覚的なレイアウトをスタイル化している場合、サイトはキーボード ナビゲーションが可能なはずですが、この点を手動でテストすることが重要です。[キーボードナビゲーション戦略](https://webaim.org/techniques/keyboard/)の詳細については、こちらをご覧ください。
|
||||
|
||||
✅ 任意のウェブサイトにアクセスして、キーボードだけを使ってナビゲートしてみてください。何がうまくいき、何がうまくいかないのでしょうか？なぜでしょうか？
|
||||
|
||||
## まとめ
|
||||
|
||||
ある人にとってアクセシブルな Web は、真の意味での「ワールドワイドな Web」ではありません。作成するサイトがアクセシブルであることを保証する最善の方法は、アクセシビリティのベストプラクティスを最初から取り入れることです。余分なステップがありますが、これらのスキルをワークフローに組み込むことで、作成するすべてのページがアクセシブルになることを意味します。
|
||||
|
||||
---
|
||||
|
||||
## 🚀 チャレンジ
|
||||
|
||||
この HTML を手に取り、学んだ戦略を踏まえて、できるだけアクセスしやすいように書き換えてください。
|
||||
|
||||
```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">The World's Premier Turtle Fan Club</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">"I like turtles"</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="https://en.wikipedia.org/wiki/Turtle">Basic Turtle Info</a></p>
|
||||
<p class="nav-item nav-item-bull"><a href="https://en.wikipedia.org/wiki/Turtles_(chocolate)">Chocolate Turtles</a></p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="main-content">
|
||||
<div>
|
||||
<p class="page-title">Welcome to Turtle Ipsum.
|
||||
<a href="">Click here</a> to learn more.
|
||||
</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">Sign up for turtle news</span>
|
||||
</div><div class="footer-section">
|
||||
<p class="nav-header footer-title">
|
||||
Internal Pages
|
||||
</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">Semantic Example</a></p>
|
||||
</div>
|
||||
</div>
|
||||
<p class="footer-copyright">© 2016 Instrument</span>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
## レクチャー後クイズ
|
||||
[レクチャー後クイズ](.github/post-lecture-quiz.md)
|
||||
|
||||
## 復習と自己学習
|
||||
|
||||
多くの政府には、アクセシビリティの要件に関する法律があります。あなたの国のアクセシビリティに関する法律をお読みください。何が適用され、何が適用されないのか？例としては、[この政府の Web サイト](https://accessibility.blog.gov.uk/)があります。
|
||||
|
||||
## 課題
|
||||
|
||||
[Analyze a non-accessible web site](assignment.ja.md)
|
||||
|
||||
Credits: [Turtle Ipsum](https://github.com/Instrument/semantic-html-sample) by Instrument
|
||||
@@ -0,0 +1,11 @@
|
||||
# アクセスできない Web サイトを分析する
|
||||
|
||||
## 説明書
|
||||
|
||||
あなたがアクセシブルではないと思う Web サイトを特定し、そのアクセシビリティを改善するためのアクションプランを作成してください。あなたの最初のタスクは、このサイトを特定し、分析ツールを使用せずにアクセスできないと思う方法を詳細に説明し、Lighthouse 分析にかけることです。この分析結果をもとに、サイトがどのように改善されるかを示す最低10点の詳細な計画を作成してください。
|
||||
|
||||
## ルーブリック
|
||||
|
||||
| 基準 | 模範的な例 | 適切な | 改善が必要 |
|
||||
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- | --------------------------- |
|
||||
| student report | サイトがどのように不十分であるかについての段落、PDFとしてキャプチャ灯台のレポート、それを改善する方法の詳細と、改善すべき10のポイントのリストが含まれています。 | 必要な 20% が欠落している | 必要な 50% が欠落している |
|
||||
17
1-getting-started-lessons/translations/README.it.md
Normal file
17
1-getting-started-lessons/translations/README.it.md
Normal file
@@ -0,0 +1,17 @@
|
||||
# Getting Started with Web Development
|
||||
|
||||
In questa sezione del curriculum, vi saranno introdotti concetti non relativi al progetto importanti per diventare uno sviluppatore professionista.
|
||||
|
||||
### Argomenti
|
||||
|
||||
1. [Introduzione ai Linguaggi di Programmazione e agli Strumenti Necessari](1-intro-to-programming-languages/translations/README.id.md)
|
||||
2. [Concetti base di GitHub](2-github-basics/translations/README.it.md)
|
||||
3. [Concetti base di Accessibilità](3-accessibility/translations/README.it.md)
|
||||
|
||||
### Riconoscimenti
|
||||
|
||||
Concetti Base di Accessibilità è stato scritto con il ♥️ da [Christopher Harrison](https://twitter.com/geektrainer)
|
||||
|
||||
Introduzione a GitHub è stato scritto con il ♥️ da [Floor Drees](https://twitter.com/floordrees)
|
||||
|
||||
Introduzione ai Linguaggi di Programmazione e agli Strumenti Necessari sono stati scritti con il ♥️ da [Jasmine Greenaway](https://twitter.com/paladique)
|
||||
17
1-getting-started-lessons/translations/README.ja.md
Normal file
17
1-getting-started-lessons/translations/README.ja.md
Normal file
@@ -0,0 +1,17 @@
|
||||
# Web 開発を始めるにあたって
|
||||
|
||||
このセクションでは、プロの開発者になるために重要なプロジェクトベースではない概念を紹介します。
|
||||
|
||||
### トピック
|
||||
|
||||
1. [プログラミング言語と開発ツール入門](1-intro-to-programming-languages/README.md)
|
||||
2. [GitHub の基本](2-github-basics/README.md)
|
||||
3. [アクセシビリティの基本](3-accessibility/README.md)
|
||||
|
||||
### Credits
|
||||
|
||||
Basics of Accessibility was written with ♥️ by [Christopher Harrison](https://twitter.com/geektrainer)
|
||||
|
||||
Introduction to GitHub was written with ♥️ by [Floor Drees](https://twitter.com/floordrees)
|
||||
|
||||
Introduction to Programming Languages and Tools of the Trade was written with ♥️ by [Jasmine Greenaway](https://twitter.com/paladique)
|
||||
Reference in New Issue
Block a user