Discussioni progetto:Accessibilità

Bar tematico del Progetto Accessibilità Nuova discussione

Questo è il bar tematico del Progetto Accessibilità. Per aprire una nuova discussione, clicca su "Nuova discussione".

La dimensione di questa pagina è attualmente 46 217 byte

Archivio

---

• 2006
• Snobismo grafico (mar 2007)
• 2007-2012
• 2013-2019
• 2020-2023
• 05

---

come archiviare  ·  modifica questa lista

Wikilink colorati

vedo che qua l'argomento colori fastidiosi esce spesso. In particolare ora parlo dei wikilink colorati manualmente, tipo così. Mi pareva fossero già vietati/sconsigliati, ma se c'è una regola non la trovo. Ovunque si faccia, il colore rovina il nostro stile fondamentale "blu=altra pagina esistente, rosso=altra pagina non ancora esistente". Con ovvi danni all'accessibilità, perché non si capisce nemmeno che quello è un link, a meno di passarci sopra col mouse, sempre che tu stia usando un mouse. Per fortuna queste cose di solito si vedono soltanto in TdN e portali, ma comunque meglio evitare. Scriviamolo chiaro e tondo in WP:Accessibilità#Colori? --Bultro (m) 01:00, 5 gen 2024 (CET)

Concordo --Pierpao (listening) 12:30, 5 gen 2024 (CET)

Segnalo questa discussione, legata ai TdN. Lì ho sottolineato proprio l'esigenza di rispettare i colori fondamentali dei wlink. Imho bisognerebbe aprire una discussione generale su colori e accessibilità, che integri la questione del colore dei wl e la questione del colore del campo su cui figura il testo. pequod76^talk 12:43, 5 gen 2024 (CET)

Concordo con Bultro. P.S. Colori nei link li ho visti anche nelle firme, ma quello penso sia un discorso un po' diverso. --Meridiana solare (msg) 13:36, 5 gen 2024 (CET)

La questione dell'accessibilità dei colori fa riferimento a 2 criteri delle WCAG: 1) "Il colore non deve essere utilizzato come unica modalità visiva per rappresentare informazioni, indicare azioni, richiedere risposte o come elemento di distinzione visiva" 2) "La rappresentazione visiva del testo e di immagini contenenti testo ha un rapporto di contrasto di almeno 4.5:1". In soldoni posso usare il colore che voglio purchè abbia un contrasto adeguato con lo sfondo e purchè non sia l'unico elemento per veicolare un qualche tipo di informazione (es. clicca sulla parola in rosso: mela, arancia, susina, banana). In pratica la nostra distinzione link blu/link rossi sarebbe visivamente inaccessibile per una persona cieca ai colori. Abbiamo ovviato con un tooltip adeguato che per i link rossi ci informa che la pagina non esiste. Ad ogni modo concordo che usare colori diversi dal blu e rosso per i link sia fuorviante e inutile. --Beatrice (msg) 01:01, 6 gen 2024 (CET)

La pagina WP:Accessibilità dovrebbe riguardare solo i problemi specifici degli ipovedenti? Allora forse WP:Wikilink è il posto più adatto per mettere la raccomandazione --Bultro (m) 03:16, 7 gen 2024 (CET)

Sui colori dei navbox sportivi

Segnalo discussione al progetto sport. --Atlante (msg) 23:24, 28 feb 2024 (CET)

Proposta di tavolozza colori

È già al bar, ma per sicurezza segnalo anche qui: Wikipedia:Bar/Discussioni/Introduzione di una tavolozza di colori per maggiore accessibilità. --Daimona Eaytoy (Scrivimi!) 22:34, 16 mag 2024 (CEST)

Colori nelle firme

Sulla base delle indicazioni contenute su Wikipedia:Accessibilità_del_contenuto#Firme_utente ieri ho fatto qualche prova per modificare il secondo colore della mia firma, in quanto i programmi mi davano un contrasto troppo basso rispetto allo sfondo giallino del namespace talk. L'avevo modificata in verde, rendendomi però conto che poi sarebbe comunque divenuta troppo poco in contrasto con lo sfondo verdognolo del namespace wikipedia. Un contrasto di almeno 4.5 è davvero limitante, e se lo dobbiamo tarare contemporaneamente su bianco, giallino e verde, credo rimangano come colori utilizzabili solo rosso e nero. Non ha senso prevedere obiettivi un po' meno ambiziosi ma realizzabili? ----Friniate^Arengo 18:34, 17 mag 2024 (CEST)

La firma di default

Domanda forse stupida: ma la firma com'è impostata ora di default, se non ricordo male di color blu chiaro, è accessibile secondo Wikipedia:Accessibilità_del_contenuto#Firme_utente? --Pątąfişiķ 12:16, 22 mag 2024 (CEST)

[@ Patafisik] La firma di default (ho cercato la mia vecchia) è visualizzata con il colore Codex --color-progressive #36c      che applicato su sfondo

• #ffffff      (bianco) dà contrasto 5.36
• #ffffee      (giallastro) 5.31
• #eeffee      (verdognolo) 5.15
• #f5fafa      (grigetto) 5.09
• #f1f1f1      (grigetto) 4.75
• #ffeeee      (rossastro) 4.78
• #f0eeff      (bluetto) 4.69
• #202122      (neretto) dà 3.00 (credo che però venga usato un'altro colore con la modalità scura). — $ZandDev ↩ 20:37, 22 mag 2024 (CEST)

Quindi, stando a quello che diceva Civvì ("il contrast ratio dovrebbe essere maggiore di 4.5") va bene. Be', me l'aspettavo ma meglio una verifica in più nel dubbio. ^^" --Pątąfişiķ 11:55, 26 mag 2024 (CEST)

Infatti diventa --color-progressive #6d8af2      che dà contrasto 5.04. — $ZandDev ↩ 20:22, 4 giu 2024 (CEST)

Firma accessibile in modalità scura

In modalità scura come sarà gestita la firma?

1. Avremo tutti firme uguali di default con colore accessibile
2. ci sarà permesso di creare una firma personalizzata anche per il dark mode
3. avremo la stessa firma per la modalità chiara e scura?

Chiedo perché dai miei test ho visto che è molto difficile avere una firma accessibile sia per la modalità chiara che per la modalità scura.--Pątąfişiķ 12:59, 30 mag 2024 (CEST)

Ho notato che il colore della mia firma cambia da modalità scura e chiara ma non mi è chiaro il criterio. Ho quindi dovuto cercare dei colori che siano accessibili in modalità chiara e che quando vengono trasformati al di fuori della mia volontà in altri colori in modalità scura questi siano ugualmente accessibili, un lavoraccio che non credo che tutti gli utenti siano disposti a fare.

Segnalo anche questo commento di [@ ValterVB].--Pątąfişiķ 10:31, 4 giu 2024 (CEST)

[@ Patafisik] Bella domanda. Per punti:

1. Significherebbe non poter personalizzare più la firma (mmh non sarebbe per nulla indolore).
2. Sarebbe top.
3. Credo che sia quello attualmente in vigore.

Se però non si va a sovrascrivere i colori di default (quindi usando i nativi token Codex) quando si passa alla modalità scura i colori assegnati ai token cambiano (basta ispezionare la pagina e vedere i colori sul selettore :root). — $ZandDev ↩ 20:40, 4 giu 2024 (CEST)

E poi credo che tu non abbia controllato che i colori fratelli siano ugualmente accessibili, la transizione tra "Pata" e "Fisik" non è più netta come prima... (impostando uno come sfondo dell'altro si ottene un contrasto di 1.02). — $ZandDev ↩ 20:43, 4 giu 2024 (CEST)

@ZandDev Non credo sia importante che le due parti del mio nome abbiano un contrasto forte l'una rispetto all'altra, di fatto se avessi scelto i colori standard entrambe sarebbero dello stesso colore blu. Purtroppo, come dicevo, è estremamente laborioso fare dei test di accessibilità su dei colori che non si possono impostare in anticipo, questo penalizza anche la ricerca della combinazione preferita. --Pątąfişiķ 09:21, 5 giu 2024 (CEST)

Ma questo cambiamento non voluto e non specificato è ... "un bug o una feature"? E riguarda solo la firma? --Meridiana solare (msg) 09:37, 5 giu 2024 (CEST)

Certo che sarebbero state delle stesso colore, però nella firma standard ci sono anche le parentesi che separano le due parti.

Comunque neanch'io ho ben inteso che cosa sia questo "cambiamento" non ben specificato. — $ZandDev ↩ 13:19, 6 giu 2024 (CEST)

[@ Patafisik] Ho già provato a fare una ipotesi ma senza un esempio per replicare è difficile poterlo affermare con certezza. Potresti contestualizzare in cosa consisterebbe questa trasformazione indesiderata? — $ZandDev ↩ 14:59, 6 giu 2024 (CEST)

@ZandDev Il colore in modalità scura cambia ma senza che sia possibile prevedere come, perché non ci è stato detto secondo quale criterio un colore viene "trasformato" in un altro (es. passando in modalità scura, di quanto aumenta la percentuale di nero o di bianco rispetto al colore da me scelto? a che soglia di colore si inverte lo scurire/schiarire?). Attualmente passando da modalità chiara a scura:

•      (modalità chiara) diventa      (modalità scura)
•      (modalità chiara) diventa      (modalità scura)
•      (modalità chiara) diventa      (modalità scura).

Quando i criteri saranno più chiari non avro' difficoltà a personalizzare diversamente la mia firma, adesso come adesso mi tengo questa provvisoria, che è comunque più accessibile della precedente (che era un disastro). :) --Pątąfişiķ 15:11, 6 giu 2024 (CEST)

Credo che l'estensione DarkMode modifichi i colori alla radice aggiungendo la classe skin-theme-clientpref-night al tag html mentre nella maggior parte delle firme il colore viene esplicitato con un attributo style che, avendo una specificità maggiore, prevale e renderebbe il colore costante in entrambe le modalità. — $ZandDev ↩ 17:10, 6 giu 2024 (CEST)

[↓↑ fuori crono] L'estensione che ho linkato non c'entra nulla, però il resto mi pare corretto. — $ZandDev ↩ 12:59, 13 lug 2024 (CEST)

[@ Patafisik] saresti andata avanti all'infinito. Oppure avresti scoperto la supertonalità di grigio #808080      a metà strada tra il bianco più bianco che non si può  #FFFFFF  e il nero più cupo  #000000 . — $ZandDev ↩ 18:09, 6 giu 2024 (CEST)

[@ patafisik] Puoi mostrarmi del codice che replichi il fenomeno? — $ZandDev ↩ 15:15, 6 giu 2024 (CEST)

Hai perfettamente ragione, e ho capito anche che stavo facendo confusione io (avevo attivato due gadget per la modalità scura e avevo confuso l'effetto dell'uno con l'effetto dell'altro ^^").

1) versione mobile: non accade selezionando la modalità scura così come spiegato in questa discussione, i colori della mia firma non cambiano (esempio).

2) versione desktop Vector 2022: non accade con la funzionalità in Beta "Accessibilità per la lettura (Vector 2022)", attivabile in Speciale:Preferenze#mw-prefsection-betafeatures. Cliccandoci sopra, tutto passa in modalità scura, la mia firma mantiene i colori che ho scelto. (esempio selezionando nella barra laterale destra Aspetto > Colore > Scuro)

3) invece accade attivando in Speciale:Preferenze#mw-prefsection-gadgets il gadget "Modalità scura: aggiunge un link che consente di visualizzare il sito con sfondi scuri e testi chiari", che aggiunge la Modalità scura tra i link del Menu utente, esempio. La mia firma cambia colore come detto sopra, ma essendo solo un gadget utente non riguarda l'implementazione della modalità scura in corso ad opera del Web Team della WMF.

Applicandosi solo sulle pagine mobile e in NS0 il sistema 1) per ottenere la modalità scura non l'avevo testato. Ma avevo attivato sia 2) che 3), me ne accorgo solo ora, credendo che gli effetti di 3) fossero quelli di 2). Scusate la confusione, --Pątąfişiķ 17:15, 6 giu 2024 (CEST)

Se desideri puoi provare dove vuoi la modalità scura inserendo alla fine dell'URL (per es. v. qui) della pagina ?vectornightmode=1 (dove si può) oppure aggiungendo a mano skin-theme-clientpref-night nel primo tag html tramite il browser (dovrebbe funzionare ovunque). Cmq io prima di mettermi a modificare la firma aspetterei che dai piani alti consentano di attivare la dark mode anche nelle principali pagine di discussione. Pensa che adesso non sono neanche sicuro del colore di sfondo... — $ZandDev ↩ 17:54, 6 giu 2024 (CEST)

Colonne d'intestazione nelle tabelle

Buongiorno a tutti. Dopo una discussione chilometrica nel Progetto:Star Trek, mi sembrava giusto parlarne anche qui, siccome lì era stata, a parte da alcuni utenti come @Luke Stark 96, interpretata come una discussione "estetica". Dunque, quello di cui parlo è la questione delle colonne d'intestazione. Se guardate pagine come DC Extended Universe#Film, confrontandola con en:DC Extended Universe#Films, noterete una differenza sulla prima colonna. Su enwiki è d'intestazione, su itwiki no. Non solo ciò è al 100% corretto, in quanto la prima colonna è quella più importante e che dà senso a tutte le altre (levi la prima colonna, tutte le altre perdono di significato, questo anche nelle tabelle "Incassi" e "Critica", dove se levi la prima colonna le altre diventano un ammasso di dati incomprensibili), ma è anche un grosso guadagno dal punto di vista dell'accessibilità. Non avere le colonne d'intestazione rende il tutto un inferno per gli utenti che fanno uso di dispositivi come gli screen reader. Gli screen reader, ad esempio, danno la possibilità di invocare la riga desiderata (es: utente non vedente vuole sapere chi è lo sceneggiatore di un film Marvel. Se la colonna è d'intestazione, può citare il titolo del film e ottenere l'informazione desiderata, se non usa screen reader deve manualmente navigare tutta la tabella, che è un vero e proprio inferno). Pensate specialmente a franchise come il DCEU, il futuro DCU e l'MCU, che hanno decine e decine di film (specialmente quest'ultimo), ma anche a Godzilla per esempio. È impraticabile per queste persone navigare correttamente le tabelle.

Quindi, non solo è una cosa corretta, ma è una cosa davvero molto utile e che può aiutare queste persone. Noi non abbiamo guideline simili, ma prendo questa di enwiki, in quanto lì hanno una particolare attenzione per l'accessibilità, e possiamo vedere come a queste colonne sia dedicata una sezione intera, mentre purtroppo qui su itwiki sembrano non esistere affatto (a livello di codice sono implementabili, ma non vengono mai citate). Propongo quindi di stabilire una guideline a riguardo, al di là dai gusti estetici (magari a qualcuno piace di più che la prima colonna sia bianca, ma imo viene prima l'accessibilità del gusto estetico). --Redjedi23 T 12:14, 19 giu 2024 (CEST)

Faccio notare che nel progetto Star Trek non c'è consenso per considerare la prima colonna come d'intestazione, perché contiene, seppur importanti, dati come il resto, perché anche il titolo del film, come la data di uscita o la regia, sono dati, non altro. Come argomentato da me e da Bultro, appesantire la tabelle con dello sfondo grigio, quindi con righe di codice, non è necessario in questo caso. Per le tabelle incassi e critica, il dato dei titoli si differenzia già del resto comunque, in quanto unico dato non numerico della tabella, quindi secondo me non è un fatto di accessibilità, quella discussione al progetto Star Trek è stata aperta apposta per stabilire (a grandi linee) uno standard per le tabelle di franchise e serie di film, e, per motivi diversi, non c'è consenso per inserire lo sfondo grigio nella prima colonna, anche perché solo poche tabelle sono grandi, la maggioranza sono piccole (con pochi film), e quindi perfettamente leggibili e accessibili anche per chi ha problemi di vista o altro--Luke Stark 96 (msg) 12:23, 19 giu 2024 (CEST)

Altra cosa, mentre per le tabelle incassi e critica c'è un altro utente (Mannivu) che considera potenzialmente corretta la prima colonna come d'intestazione, nella tabelle dei film (le prime che si vedono in queste pagine), solo Redjedi sostiene che vadano come d'intestazione, quindi accessibilità o meno, e per me e altri non è questo il caso, c'è anche un WP:CONSENSO a riguardo, e anche se non sono intervenuti tantissimi utenti, solo uno sostiene che vada considerata come d'intestazione--Luke Stark 96 (msg) 12:29, 19 giu 2024 (CEST)

A parte l'estetica, nell'altra discussione ho spiegato perché non sono intestazioni. Se si considerassero tali, più o meno tutte le tabelle di wikipedia dovrebbero avere una colonna grigia; un lavoro folle che non si farà mai. E prima di sparare cos'è un "inferno" per i non vedenti, si parta da un vero non vedente che fa una vera lamentela. --Bultro (m) 02:01, 20 giu 2024 (CEST)

L'accessibilità è un concetto fondamentale importate per rendere fruibile e libera per tutti la conoscenza. Wikipedia non può rendere davvero la conoscenza libera se non è accessibile. Deridere le esigenze dei non vedenti o di qualunque altro utente con diversa abilità, fosse anche temporanea, è un'affermazione che mi stupisce davvero in questo contesto. Chiunque di noi può installare sul proprio pc uno screen reader, farlo partire, chiudere gli occhi e capire cosa vuol dire leggere una tabella senza intestazioni. La tabella diventa inutile. La tabella è inutile comunque per chiunque se ti toglie quella colonna, come giustamente ci faceva notare Redjedi23, quindi quei dati sono fondamentali e fanno da riferimento per tutti i restanti, ed è questo il concetto delle intestazioni. Anche il testo contenuto nelle intestazione è un dato, per chi non ne fosse consapevole. L'accessibilità non è un vezzo. Non stiamo scegliendo se ci piace di più il rosa pallido o il verde acido, stiamo rendendo la conoscenza libera per tutti. Sono consapevole che ci sia davvero poca consapevolezza di quanto sia importante l'accessibilità, e che soprattutto in Wikipedia ci sia un enorme lavoro da fare, ma certo non può spaventarci farlo se abbiamo scritto un'enciclopedia da zero. Impuntarsi per mantenere una tabella inaccessibile è contrario allo spirito wikipediano. Per chi fosse proprio a digiuno di cosa sia l'accessibilità, consiglio di partire dai video degli Accessibility Days, reperibili su Youtube, dove potrete confrontarvi con la realtà quotidiana di abili e diversamente abili. --Beatrice (msg) 23:09, 20 giu 2024 (CEST)

Questo però non vuol dire che ogni prima colonna di ogni tabella debba essere d'intestazione, il titolo del film non è l'unico dato importante, anche le date di uscita lo sono, e nelle tabelle degli incassi la colonna degli incassi mondiali è anche più importante del titolo, altrimenti l'intera tabella non ha più senso di esistere, ma questo non significa che quella colonna vada considerata come d'intestazione. In queste tabelle (quelle generali, oppure su incassi e critica), tutti i dati sono importanti, ma non per questo tutte le colonne vanno considerate d'intestazione, e i titoli sono dei dati all'interno di una tabella di dati, quindi perché proprio quella colonna va messa come d'intestazione e non un'altra? Perché è la prima? E se mettessimo le date di uscita nella prima colonna dovremmo mettere quella come d'intestazione?--Luke Stark 96 (msg) 23:25, 20 giu 2024 (CEST)

(fuori crono) Ciao Luke Star. Il titolo del film nella tabella DC Extended Universe#Film è un dato imprescindibile. Prova mentalmente a cancellare una per volta le colonne e poi a rimetterle. La tabella mantiene un senso se togli qualunque colonna tranne quella del titolo. Quella colonna dà significato a tutta la riga, senza di essa è un insieme di dati senza senso. Non è un caso che sia stata messa proprio per prima. Potresti spostare ad esempio per prima la colonna relativa al regista, ma allora quella sarebbe una tabella relativa ai registi, ma non funzionerebbe perchè i dati non si riferiscono ai registi (cosa vuol dire ad es. "data di uscita USA" riferito a un regista?). E' come se giocassi a battaglia navale senza avere la prima colonna. Anche quelli contenuti nelle intestazioni sono dati e forse questo ti confonde. Prova davvero a scaricare uno screen reader (io uso NVDA) e ti renderei conto che il lettore ripete le intestazioni di riga e di colonna per ogni dato proprio per renderlo comprensibile. Ad esempio, se la tabella fosse accessibile, leggerebbe posizionato nella cella B2 "L'uomo d'acciaio, Data di uscita USA, 14 giugno 2013". Ma se le intestazioni non sono state definite, il lettore legge solo "colonna 2, 14 giugno 2013", che non vuol dire nulla. Cosa è il 14 giugno 2013? A cosa si riferisce? Per quale film? --Beatrice (msg) 23:56, 20 giu 2024 (CEST)

Più nello specifico: se nella tabella incassi, ad esempio, togliessimo la colonna dei titoli, la tabella diventa inutile? Vero. Ma lo stesso discorso vale anche per la colonna degli incassi mondiali, che, insieme alla colonna dei titoli, sono le uniche due "obbligatorie" in queste tabelle, perché non ha senso mettere solo l'incasso in Italia o negli USA ecc. Queste due colonne hanno uguale importanza, mettiamo entrambe come d'intestazione? Se la risposta è "no, solo quella dei titoli", perché? E lo stesso discorso per la tabella critica, se togli la colonna dei titoli, la tabella diventa inutile? Vero anche qui, ma vale lo stesso se togli le colonne delle recensioni di Rotten Tomatoes e Metacritic (ci sono questi due siti di solito), altrimenti non ha senso fare la tabella. Riassumendo, buona parte delle colonne, se tolte, fanno perdere di senso l'intera tabella, non solo quella dei titoli, quindi perché considerarne una più importante delle altre quando al massimo è "alla pari" con almeno un'altra?--Luke Stark 96 (msg) 23:40, 20 giu 2024 (CEST)

Aspè, non seguo abbastanza il progetto per ricordare tutte le tabelle a memoria :) Di quali tabelle parli in questo caso? --Beatrice (msg) 23:59, 20 giu 2024 (CEST)

[↓↑ fuori crono] No, non hanno eguale importanza. Se nella tabella levi gli incassi mondiali, succede che diverrebbe una tabella relativa agli incassi dell'Italia e degli Stati Uniti, ad esempio. Avrebbe senso comunque, perché potresti dire "Ah ok, manca l'incasso globale, ma vedo che Iron Man ha incassato xxx$". Se levi la colonna dei titoli invece non puoi ricavarne NESSUNA informazione utile. Letteralmente nessuna.

La roba delle recensioni non ha senso, ovvio che se levi tutte le altre colonne perde tutto di significato, io sto dicendo "leva solo una colonna e vedi se senza quella colonna riesci comunque a ottenere delle informazioni logiche e sensate dalla tabella". Secondo il tuo discorso, dovremmo togliere le righe d'intestazione, perché se cancelli tutte le altre righe allora anche la riga d'intestazione diventa inutile, e grazie tante.

@Beatrice ha perfettamente colto ciò che intendevo. --Redjedi23 T 00:00, 21 giu 2024 (CEST)

Nel senso, se levi la colonna "Mondiale" dalla tabella "Incassi" la tabella è al massimo incompleta, non fuori da ogni logica e incomprensibile, cosa che lo sarebbe se levi il titolo del film. Stessa cosa per la "Critica", se levi la colonna su RT, hai comunque una tabella perfettamente sensata e logica, in cui sono elencati i dati relativi a Metacritic. La prima colonna in questo caso è palesemente la più importante. --Redjedi23 T 00:04, 21 giu 2024 (CEST)

Beatrice, intendo le due tabelle come quelle in DC Extended Universe#Accoglienza. E sì che la colonna degli incassi globali è fondamentale, la tabella incassi potrebbe essere benissimo composta solo da titoli e incassi mondiali, tutto il resto è "un di più" opzionale, utile ma non obbligatorio, ma se non metti gli incassi globali che senso ha fare la tabella? Una tabella composta solo dagli incassi in Italia, ad esempio, sarebbe localismo e andrebbe cancellata, perché in quelle condizioni è inutile, oltre a essere contro le linee guida, ma la colonna degli incassi globali e l'unica, insieme a quella dei titoli, che non può mancare--Luke Stark 96 (msg) 00:09, 21 giu 2024 (CEST)

(f.c.) Scusate, capito ora a quale tabella facevi riferimento. Solo che nel frattempo ho visto la tabella dei personaggi. Quella è davvero tosta, sia che tu non abbia gli occhi buoni sia che tu li abbia. Tutte quelle celle unite, i grigi che ti fanno perdere i riferimenti delle intestazioni, non aiutano. In questi casi è meglio suddividere la tabella o farne versioni semplificate. Tornando a noi, chiaro che se vuoi fare una tabella degli incassi x film devi mettere almeno questi 2 dati, e solo in questo specifico caso, non avrebbe senso mettere un'intestazione perchè i dati diventerebbero quasi paritari (in realtà però dipende da cosa vuoi mettere in evidenza). Ma già se aggiungi un terzo dato per riga una delle colonne è l'intestazione. --Beatrice (msg) 00:18, 21 giu 2024 (CEST)

Sì ma il discorso che fai tu riguarda la completezza della tabella. Ovvio che sarebbe insensata una tabella del genere, così come sarebbe insensato proporre una tabella con una colonna in meno su Napoli#Clima, eppure anche lì solo una delle colonne d'intestazione. Il discorso ripeto è che senza gli incassi mondiali è comunque una tabella che ha un senso logico, una persona riuscirebbe a interpretarne facilmente i dati anche se c'è un informazione mancante, non direbbe "aspetta non ci sto capendo letteralmente nulla". Se levi quella dei film invece sì.

Sulla frase di Bultro che sarebbe un lavorone dico che non dobbiamo nasconderci dietro a questo argomento fantoccio pur di rigettare il progresso e il cambiamento in favore del mantenimento dello status quo, sia perché Wikipedia è un WiP costante sia perché in questo modo resteremmo ancorati a una visione del web ferma agli anni 2000. Sulla parte che la lamentela deve partire da una persona con disabilità stendo un velo pietoso. Un attacco personale evitabile, dovresti argomentare nel merito, questo è tutto fuorché un argomento nel merito. --Redjedi23 T 00:16, 21 giu 2024 (CEST)

C'è anche il discorso sulla grandezza della tabella di cui hai parlato, posso capire per le tabelle grandi, ma ci sono tante tabelle (nell'ambito film), che contengono solo pochi film, davvero è difficile comprendere anche le tabelle così piccole? Se è così, invece che dover fare un "lavorone" per adattare le esistenti tabelle, facciamo prima a cancellarle queste tabelle, se rendono davvero la vita complicata a qualcuno. Ovviamente è una provocazione la mia, spero non vi offendiate, era per cercare di farmi capire--Luke Stark 96 (msg) 00:22, 21 giu 2024 (CEST)

Anche tu Luke non devi offenderti se cerchiamo di spiegare questo concetto che non è sempre facilmente intuibile per chi è abituato a leggere da anni quelle tabelle, anzi addirittura abituato ad editarle! Ma l'accessibilità serve a tutti perchè vuol dire rendere un'informazione facilmente fruibile ad ogni livello. E la tabella può essere grande o piccola a piacere, ma se l'unico mezzo che hai a disposizione per leggerla è un lettore di schermo, per te è un muro invalicabile un dato inaccessibile. M< non dobbiamo scoraggiarci. Ci sono persone che lavorano costantemente nel cercare soluzioni adatte in ogni contesto. Penso che la strada migliore per wikipedia sia standardizzare le tabelle fornendo alcuni modelli accessibili da cui partire. Niente di insormontabile per noi. --Beatrice (msg) 00:30, 21 giu 2024 (CEST)

[← Rientro] Beatrice, ma io non sono offeso :) capisco il vostro punto di vista, che non coincide con il mio, non ne farò una tragedia se si deciderà di implementare queste colonne--Luke Stark 96 (msg) 00:33, 21 giu 2024 (CEST)

Grazie Luke. Per me editare queste tabelle è sempre stata una sfida, ma ho verificato che con lo strumento di modifica diventa leggermente più semplice. Ho provato ad esempio ora a dividere 2 celle che erano state unite perchè contenenti lo stesso dato. Anche queste unioni dovrebbero essere evitate quanto più possibile proprio per come funzionano i lettori di schermo. Un'altra semplice prova che invito a fare è quella di usare l'ingranditore di schermo, molto usato dagli ipovedenti. Vedere una pagina così ingrandita fa perdere facilmente i riferimenti. Anche per questo tabelle troppo lunghe risultano tanto difficili da leggere. --Beatrice (msg) 00:46, 21 giu 2024 (CEST)

Beh se per te editare queste tabelle è complicato, lo diventerà un pochino di più ancora se aggiungessimo l'intestazione, perché dovremmo aggiungere del codice aggiuntivo a ogni riga, quindi se le tabelle sono complicate da modificare questa implementazione non le semplifica, anzi--Luke Stark 96 (msg) 01:07, 21 giu 2024 (CEST)

Per questo auspico la produzione di "tabelle tipo" accessibili da cui partire. Anche lo strumento di modifica potrebbe e dovrebbe essere implementato per tenere conto dei requisiti per l'accessibilità. Non possiamo rimanere agli anni 2000 come dice Redjedi. --Beatrice (msg) 09:04, 21 giu 2024 (CEST)

Lo strumento di modifica dovrebbe essere migliorato senza dubbio. Comunque @Luke Stark 96 anche per tabelle piccole, come dice @Beatrice, ha una grossa utilità. Alla fine i franchise cinematografici non sono poi così tanti, e non tutte le pagine di questo tipo hanno tabelle (dovrebbero averle tutte, ma alcune semplicemente non sono state ancora inserite). Se il problema è che ci vorrà tempo, meglio tardi che mai. Inoltre, posso assumermi personalmente la responsabilità di standardizzare, ove necessario, TUTTE le tabelle dei franchise che necessitano della colonna d'intestazione. Se posso aiutare un gruppo di persone ad avere un'esperienza migliore, sono felice di farlo. Inoltre il fatto che modificare sia difficile, e ripeto lo è indubbiamente, non vuol dire che dobbiamo render difficile anche la fase di lettura :-) Se riusciamo a migliorare anche solo una delle due è già un enorme passo in avanti. Ma ripeto, se il problema è questo, mi posso assumere personalmente questa responsabilità. --Redjedi23 T 11:41, 21 giu 2024 (CEST)

Per le tabelle piccole, ripropongo il commento di Beatrice: «se la tabella fosse accessibile, leggerebbe posizionato nella cella B2 "L'uomo d'acciaio, Data di uscita USA, 14 giugno 2013". Ma se le intestazioni non sono state definite, il lettore legge solo "colonna 2, 14 giugno 2013", che non vuol dire nulla. Cosa è il 14 giugno 2013? A cosa si riferisce? Per quale film?»

Ciò vale anche per quei franchise con 3—5 film. Perché non dobbiamo migliorare l'esperienza di gruppi di persone quando abbiamo il potere di farlo? --Redjedi23 T 11:44, 21 giu 2024 (CEST)

Ignorando un attimo il discorso film, vi porto un altro esempio: en:Open carry in the United States. Se un utente che fa uso di screen reader volesse rapidamente consultare la situazione per quanto riguarda l'open carry in Florida gli risulterebbe semplicissimo... su enwiki. Perché su itwiki non le usiamo queste colonne d'intestazione. Tralasciando dunque i film, questa questione delle colonne d'intestazione, e magari della classe plainrowheaders, può davvero risultare molto utile in tantissimi campi. --Redjedi23 T 19:23, 24 giu 2024 (CEST)

Aggiungo che le linee guida per l'accessibilità (WCAG) riportano questo criterio al 1.3.1 Informazioni e correlazioni, da dove partire per approfondire la questione. Volendo, un testo leggermente meno tecnico si trova ad es. sul sito di Adobe in Creazione di contenuto accessibile (conformità WCAG 2.1). Non si tratta quindi di pareri soggettivi, ma di seguire delle linee guida internazionali per assicurare a tutti di poter leggere le nostre voci in modo davvero libero. --Beatrice (msg) 21:57, 24 giu 2024 (CEST)

Comunque ok, non si trova consenso sull'adozione delle colonne d'intestazione per le tabelle dei film. Però la classe plainrowheaders la vogliamo implementare? Sono tantissimi i casi in cui può tornare utile, come appunto en:Open carry in the United States. Almeno in questo modo non abusiamo sempre del grassetto. --Redjedi23 T 17:58, 6 lug 2024 (CEST)

@Beatrice, @Bultro, @Luke Stark 96 Ciao scusatemi, fatemi sapere se per i casi come quello indicato sopra siete d'accordo con l'introduzione di questa classe. Non sarebbe una sostituzione totale del grassetto e del testo al centro, sarebbe una possibilità per rendere più gradevoli visivamente quelle tabelle che già hanno le colonne d'intestazione qualora dovesse esser necessario (se dovesse esistere una pagina come "Open carry in the United States" qui, che sarebbe al 100% enciclopedica, mi farebbe bruttissimo vedere tutto in grassetto)

Specifico: non sto parlando delle tabelle sui film, non voglio riaprire l'argomento a riguardo. --Redjedi23 T 13:53, 1 ago 2024 (CEST)

Ciao [@ Redjedi23] io, come sai, "faccio parte" solo del progetto cinema (e un po' fumetti, ma poco), quindi io rimango contrario per le tabelle di film, franchise e altro, per quanto riguarda tutto il resto mi astengo, nel senso che ne so troppo poco per capire se siano davvero utili, lascio esprimere chi ne sa più di me--Luke Stark 96 (msg) 14:02, 1 ago 2024 (CEST)

anzitutto l'"attacco personale" (accusa fatta tempo fa ma l'ho letto adesso) e il "deridere" chicchessia sono un frutto della vostra immaginazione, per piacere evitiamo queste sparate ridicole.

Il punto è che chi usa veramente uno screen reader parlerebbe con cognizione di causa, mentre noi qua facciamo ipotesi. Dover leggere 50 prime caselle di riga non è tanto meglio che dover leggere 50 righe, e chi ci convive quotidianamente con queste situazioni probabilmente le sa gestire meglio che stare lì a farsi elencare tutti i 50 stati USA o quel che è. Non c'è solo la lettura integrale della pagina, gli screen reader consentono di spostarsi sulla casella che si vuol leggere, si può ricercare nel testo e quant'altro.

Se invece siamo tornati a parlare del "gradevole", questo progetto non è il posto giusto. Per me comunque il plainrowheaders di en.wiki non è gradevole; la colonna o è intestazione (grassetto-grigio-centrato), o non lo è (nessuno dei tre). Per me quelle di cui sopra non sono intestazioni, ma se considerarle intestazioni deve servire (forse) per gli screen reader, si potrebbe usare una classe invisibile con sola funzione tecnica.--Bultro (m) 00:00, 4 ago 2024 (CEST)

Colori dei diff nel mediawiki

A proposito di accessibilità, ma non trovate anche voi che i nuovi colori dei diff nel mediawiki con quel nero su viola, siano davvero poco accessibili? Non avrebbe senso chiedere a WMF di modificarli (almeno tornare all'azzurrino di prima)? ----Friniate ✉ 15:15, 20 giu 2024 (CEST)

Concordo, preferivo di gran lunga come era prima, ora vedo arancione per il testo originale e viola per quello aggiunto--Luke Stark 96 (msg) 15:18, 20 giu 2024 (CEST)

E ho chiesto il perché di questo cambiamento all'officina--Luke Stark 96 (msg) 15:23, 20 giu 2024 (CEST)

Ripeto quanto scritto anche in Officina.

Prima, se la modifica riguardava pochi caratteri (tipico, aggiunta o eliminazione di una virgola) era impossibile rintracciarla; adesso finalmente si vede quindi spero che non si torni indietro.

Il viola si può schiarire un po' o magari sostituire con un verde carico. IMHO. --Antonio1952 (msg) 22:27, 20 giu 2024 (CEST)