---
schema_version: "1"
id: 102539f29a6aabad67e52c8d0c53ea3044ac77f10a9071ec980923831c23a298
title: Accessibilità e progettazione inclusiva - Schemi
collection: architect
version: current
locale: it-it
portal_url: https://docs.salesforce.com/architect/current/it-it/well-architected/guides/fairness-accessibility-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/it-it/well-architected/guide/fairness-accessibility-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: aa157f6d897b3380ab2b248bf257e3f96e288bc368eba6beec733bc3321395a0
products:
  - Framework ben progettato
  - Architect Site Content Repo
---
# Accessibilità e progettazione inclusiva - Schemi

<br>

Ulteriori informazioni sull'[equità](/docs/architect/it-it/well-architected/guide/fairness.html) ben progettata → [accessibilità con Lightning ed Experience Cloud](/docs/architect/it-it/well-architected/guide/fairness.html#accessibility-with-lightning-and-experience-cloud)

## Conformità WCAG 2.2 AA

**Schemi**

| Dove cercare | Che bell'aspetto |
| --- | --- |
| Piattaforma \| Standard di progettazione               | ✅ WCAG 2.2 Level AA è la barra di accessibilità minima per i lavori personalizzati (Experience Cloud, LWC, temi personalizzati), verificati dal team di costruzione                                                |
| Piattaforma \| Standard di progettazione               | ✅ Principio percepibile: Esistono alternative testuali per immagini e icone; le didascalie accompagnano i video   |
| Piattaforma \| Standard di progettazione               | ✅ Principio di funzionamento: Tutte le funzionalità sono utilizzabili solo tramite tastiera, senza necessità di mouse o tocco: le tecnologie di controllo vocale e di assistenza per l'accesso tramite switch si basano sullo stesso modello di tastiera/messa a fuoco             |
| Piattaforma \| LWC                            | ✅ I componenti Web Lightning standard vengono utilizzati come progettato, fornendo automaticamente l'accessibilità di base                                         |
| Piattaforma \| LWC                            | ✅ I componenti personalizzati implementano l'accessibilità esplicita convalidata tramite test con screen reader                                               |
| Piattaforma \| Piani di test                     | ✅ Il test di accessibilità è incluso in tutte le fasi di test (non ad hoc o facoltativo)                                                               |

**Anti-schemi**

| Dove cercare | Che brutto aspetto |
| --- | --- |
| Piattaforma \| Standard di progettazione               | ⚠️ WCAG 2.2 Livello AA è considerato facoltativo o "bello da avere" anziché requisito minimo                           |
| Piattaforma \| Standard di progettazione               | ⚠️ Le immagini e le icone sono prive di alternative testuali; i video sono privi di didascalie                                                        |
| Piattaforma \| Standard di progettazione               | ⚠️ La funzionalità richiede l'interazione del mouse o del tocco senza alternative da tastiera                              |
| Piattaforma \| LWC                            | ⚠️ I componenti personalizzati vengono creati senza implementazione o convalida dell'accessibilità                                       |
| Piattaforma \| LWC                            | ⚠️ I componenti di input personalizzati utilizzano elementi div e stile CSS senza significato semantico o accessibilità da tastiera          |
| Piattaforma \| Piani di test                     | ⚠️ I test di accessibilità sono ad hoc, facoltativi o eseguiti solo prima del lancio (non durante lo sviluppo)              |

## Architettura dello screen reader

**Schemi**

| Dove cercare | Che bell'aspetto |
| --- | --- |
| Piattaforma \| LWC                            | ✅ Gli elementi HTML semantici (intestazione, navigazione, principale, a parte, piè di pagina, articolo, sezione) vengono utilizzati nei componenti Web Lightning personalizzati                      |
| Piattaforma \| LWC                            | ✅ I punti di riferimento, i ruoli e le proprietà di ARIA vengono applicati dove HTML semantico da solo non può trasmettere il comportamento dell'interfaccia                                 |
| Piattaforma \| LWC                            | ✅ Gli aggiornamenti dinamici del contenuto utilizzano le regioni in diretta che annunciano le modifiche agli utenti screen reader                                                      |
| Piattaforma \| LWC                            | ✅ I componenti interattivi personalizzati hanno definizioni di ruolo esplicite corrispondenti al loro comportamento                                                         |
| Piattaforma \| LWC                            | ✅ Le etichette dei moduli sono associate esplicitamente a tutti gli input dei moduli utilizzando elementi di etichetta appropriati o attributi aria-labeledby                         |
| Piattaforma \| LWC                            | ✅ I componenti di input Lightning sono configurati con attributi di etichetta obbligatori che forniscono l'associazione di etichette incorporata                                |
| Piattaforma \| Piani di test                     | ✅ Il test viene condotto con screen reader effettivi: JAWS e NVDA su Windows, VoiceOver su macOS e iOS, TalkBack su Android                   |
| Piattaforma \| Piani di test                     | ✅ Il test manuale con tecnologia di assistenza reale viene eseguito da persone che capiscono come gli utenti screen reader navigano                         |
| Piattaforma \| Standard di progettazione               | ✅ Il testo segnaposto non viene mai utilizzato come unica etichetta perché i segnaposto scompaiono a fuoco e forniscono un contesto insufficiente per gli screen reader |

**Anti-schemi**

| Dove cercare | Che brutto aspetto |
| --- | --- |
| Piattaforma \| LWC                            | ⚠️ Strisce di markup Div-heavy che significano dalla gerarchia dei contenuti costringendo gli utenti screen reader a navigare in modo lineare |
| Piattaforma \| LWC                            | ⚠️ ARIA non viene utilizzato dove HTML semantico da solo non può trasmettere il comportamento dell'interfaccia                             |
| Piattaforma \| LWC                            | ⚠️ Gli aggiornamenti dinamici del contenuto non utilizzano le regioni in diretta; gli utenti dello screen reader perdono modifiche importanti        |
| Piattaforma \| LWC                            | ⚠️ I componenti interattivi personalizzati non hanno definizioni di ruolo esplicite; gli screen reader le annunciano in modo non corretto  |
| Piattaforma \| LWC                            | ⚠️ Gli input del modulo non contengono un'associazione esplicita delle etichette; il testo segnaposto viene utilizzato come unica etichetta                     |
| Piattaforma \| Piani di test                     | ⚠️ Vengono utilizzati esclusivamente strumenti di accessibilità automatici; non vengono eseguiti test manuali dello screen reader       |
| Piattaforma \| Piani di test                     | ⚠️ I test sono condotti da utenti non vedenti che non hanno familiarità con il modo in cui gli utenti screen reader navigano effettivamente         |

## Navigazione da tastiera

**Schemi**

| Dove cercare | Che bell'aspetto |
| --- | --- |
| Piattaforma \| Standard di progettazione               | ✅ La funzionalità completa è accessibile tramite tastiera senza richiedere l'interazione del mouse o del tocco in qualsiasi punto dei journey degli utenti                       |
| Piattaforma \| LWC                            | ✅ L'ordine di messa a fuoco logico segue il layout visivo e il flusso di interazione                                                                                     |
| Piattaforma \| LWC                            | ✅ Quando si caricano contenuti dinamici o si aprono le finestre modali, l'attivazione viene gestita a livello di programmazione per guidare gli utenti della tastiera verso nuovi contenuti                                |
| Piattaforma \| LWC                            | ✅ I componenti modali e popover spostano l'attivazione sul titolo modale o sul primo elemento interattivo all'apertura; tornare attivo per attivare il pulsante alla chiusura               |
| Piattaforma \| Standard di progettazione               | ✅ Gli indicatori di messa a fuoco visibili mostrano chiaramente quale elemento ha sempre la tastiera attiva                                                                |
| Piattaforma \| Standard di progettazione               | ✅ Gli indicatori di messa a fuoco soddisfano il requisito di contrasto 3:1 rispetto al contenuto circostante                            |
| Piattaforma \| LWC                            | ✅ Gli utenti possono navigare all'interno e all'esterno di tutti i componenti utilizzando solo la tastiera senza rimanere intrappolati                                                    |
| Piattaforma \| LWC                            | ✅ I dialoghi modali intrappolano l'attivazione all'interno della finestra modale mentre sono aperti (impedendo l'accesso ai contenuti oscurati) ma rilasciano l'attivazione su Chiudi                            |
| Piattaforma \| Standard di progettazione               | ✅ Le scelte rapide da tastiera per le azioni frequenti evitano conflitti con le scelte rapide dello screen reader e le scelte rapide del browser                                         |
| Piattaforma \| Standard di progettazione               | ✅ Le scelte rapide a lettera singola si attivano solo quando componenti specifici sono attivi (non globalmente) per evitare conflitti con i comandi di navigazione dello screen reader |
| Piattaforma \| Documentazione                  | ✅ Tutte le scelte rapide da tastiera personalizzate sono documentate nel contenuto della guida accessibile                                                                            |
| Piattaforma \| Piani di test                     | ✅ I passaggi di test includono la navigazione solo tastiera in tutti i journey utente senza utilizzare mouse o tocco                                                 |

**Anti-schemi**

| Dove cercare | Che brutto aspetto |
| --- | --- |
| Piattaforma \| Standard di progettazione               | ⚠️ La funzionalità richiede l'interazione con mouse o touch; gli utenti solo tastiera non possono completare le operazioni chiave           |
| Piattaforma \| LWC                            | ⚠️ L'ordine di attivazione non segue il layout visivo logico; gli utenti passano attraverso gli elementi in sequenza imprevista       |
| Piattaforma \| LWC                            | ⚠️ Le modalità si aprono senza gestione del focus; gli utenti della tastiera sono bloccati sul pulsante di attivazione ora nascosto             |
| Piattaforma \| LWC                            | ⚠️ La chiusura modale non restituisce l'attivazione al pulsante di attivazione; gli utenti devono cercare il loro posto nella pagina           |
| Piattaforma \| Standard di progettazione               | ⚠️ Gli indicatori di messa a fuoco sono soppressi per motivi estetici; gli utenti non possono vedere quale elemento ha il focus            |
| Piattaforma \| Standard di progettazione               | ⚠️ Gli indicatori di messa a fuoco hanno un contrasto insufficiente (<3:1)                            |
| Piattaforma \| LWC                            | ⚠️ Gli utenti rimangono intrappolati in aree dell'interfaccia senza meccanismo di fuga (trappole da tastiera)                        |
| Piattaforma \| LWC                            | ⚠️ Contenuto incorporato (iFrame, widget di terze parti) cattura in modo permanente l'attivazione della tastiera                        |
| Piattaforma \| Standard di progettazione               | ⚠️ Le scelte rapide a lettera singola si attivano in conflitto globale con i comandi di navigazione a lettera singola dello screen reader |
| Piattaforma \| Documentazione                  | ⚠️ Le scelte rapide da tastiera personalizzate non sono documentate; gli utenti non possono scoprirle                                     |

## Progettazione visiva e contrasto

**Schemi**

| Dove cercare | Che bell'aspetto |
| --- | --- |
| Piattaforma \| Standard di progettazione               | ✅ Rapporto di contrasto minimo 4.5:1 per testo normale sotto 18pt o grassetto 14pt                                                                |
| Piattaforma \| Standard di progettazione               | ✅ Rapporto di contrasto minimo 3:1 per testo di grandi dimensioni e per componenti e grafica significativi dell'interfaccia utente (bordi dei moduli, icone informative); gli elementi puramente decorativi e disabilitati sono esenti                      |
| Piattaforma \| Experience Cloud               | ✅ I temi personalizzati e i siti Experience Cloud con immagine aziendale includono la convalida esplicita del contrasto utilizzando strumenti di sviluppo del browser o checker automatici |
| Piattaforma \| Standard di progettazione               | ✅ Il ridimensionamento del testo al 200% è supportato senza perdita di contenuto o funzionalità (requisito WCAG)                                        |

**Anti-schemi**

| Dove cercare | Che brutto aspetto |
| --- | --- |
| Piattaforma \| Standard di progettazione               | ⚠️ I rapporti di contrasto del testo scendono al di sotto di 4.5:1 (testo normale) o 3:1 (testo grande e componenti dell'interfaccia utente)    |
| Piattaforma \| Experience Cloud               | ⚠️ I temi personalizzati vengono distribuiti senza convalida del contrasto; gli utenti ipovedenti non possono leggere il contenuto |
| Piattaforma \| Standard di progettazione               | ⚠️ Ridimensionamento testo oltre il 200% interrompe i layout perdendo contenuto o funzionalità                       |

## Test e convalida dell'accessibilità

**Schemi**

| Dove cercare | Che bell'aspetto |
| --- | --- |
| Piattaforma \| CI/CD                          | ✅ La scansione dell'accessibilità Axe-core o Lighthouse è integrata nelle pipeline CI / CD che rilevano problemi strutturali in ogni distribuzione       |
| Piattaforma \| CI/CD                          | ✅ Le build falliscono quando vengono rilevati problemi critici di accessibilità                                                                           |
| Piattaforma \| Piani di test                     | ✅ I test manuali con screen reader, navigazione solo tastiera e zoom del browser al 200% vengono eseguiti regolarmente durante lo sviluppo  |
| Piattaforma \| Piani di test                     | ✅ I test rivelano problemi di interazione, tra cui ordine degli annunci confuso, errori di gestione del focus e trappole da tastiera            |
| Piattaforma \| Business                       | ✅ Gli utenti con disabilità sono inclusi nei test di usabilità durante tutto il processo di progettazione                                                   |
| Piattaforma \| Business                       | ✅ I test di usabilità rivelano le barriere pratiche che mancano ai test esperti automatici e manuali                                            |
| Piattaforma \| Piani di test                     | ✅ Test automatici (~57% dei problemi in volume), test manuali (problemi di interazione) e test utente (barriere del mondo reale) vengono tutti eseguiti |

**Anti-schemi**

| Dove cercare | Che brutto aspetto |
| --- | --- |
| Piattaforma \| CI/CD                          | ⚠️ La scansione dell'accessibilità non è integrata nelle pipeline CI/CD                                          |
| Piattaforma \| CI/CD                          | ⚠️ Le build procedono nonostante i problemi critici di accessibilità                                                   |
| Piattaforma \| Piani di test                     | ⚠️ Non vengono eseguiti test manuali con tecnologia di supporto; viene utilizzata solo la scansione automatica             |
| Piattaforma \| Business                       | ⚠️ Gli utenti con disabilità non sono inclusi nei test di usabilità                                          |
| Piattaforma \| Piani di test                     | ⚠️ Lo scanner di accessibilità automatico viene eseguito una volta prima del lancio e il test di accessibilità è considerato completato |
