Ulteriori informazioni sull'equità ben progettata → accessibilità con Lightning ed 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 |