Comentarii

Copiați linkul Citat răspuns

joe-watkins comentat 25 aprilie 2018 •

În cadrul tehnicilor WCAG 1.4.4 există o referință la o clarificare viitoare în legătură cu o neînțelegere comună a acestui SC. Este redimensionare numai text sau zoom browser? Nimeni nu știe . sunt amândouă?

Notă: Grupul de lucru a descoperit multe neînțelegeri cu privire la modul de testare a acestui eșec. Planificăm să revizuim acest eșec într-o actualizare viitoare. Până atunci, dacă conținutul depășește criteriul de succes folosind oricare dintre tehnicile suficiente enumerate, atunci nu îndeplinește acest eșec.

Există un dezacord în legătură cu modul în care este interpretat acest SC. Unii oameni cred că zoom-ul browserului (în care totul doar mărește ctrl +/-) este o tehnică suficientă, în timp ce alții interpretează SC astfel încât mărirea textului doar la 200% nu trebuie să provoace tăierea, trunchierea textului, a imaginii sau a comenzilor. sau ascunse. Mă aplec spre acesta din urmă.

Cu rețeaua web receptivă, este destul de ușor să creați o experiență care să treacă acest SC, acesta fiind doar zoom-ul browserului cu browsere moderne care acceptă interogări media și care au zoom de browser excelent. Crearea de experiențe care funcționează cu redimensionarea numai cu text este mult mai dificilă și se bazează pe o dimensionare fluidă, nedeterminată.

Atât Firefox cât și Safari permit doar textul ca opțiune pentru zoomul nativ al browserului acum, ceea ce face lucrurile interesante.

Când vom vedea o actualizare a unora dintre aceste eșecuri aducând mai multă claritate în jurul acestui SC? 2.1 ?

Mulțumesc pentru toată munca depusă:)

Textul a fost actualizat cu succes, dar s-au întâlnit aceste erori:

alastc comentat 26 aprilie 2018 •

Prin litera textului SC pentru 1.4.4, un site va trece dacă zoomul este „accesibilitate acceptată”, adică persoanele care au nevoie de el pot folosi un browser cu zoom. Acesta este aproape întotdeauna cazul, astfel încât, din jurul anului 2009, nu a fost un criteriu deosebit de eficient decât dacă oamenii o duc mai departe.

În 2.1 avem acum „reflow”, care funcționează în combinație cu textul de redimensionare. Am făcut o imagine de ansamblu asupra acestora.

Nu putem schimba criteriile WCAG 2.0, ne bazăm pe ele și reflow & spațierea textului sunt destinate să umple golurile.

Trebuie să verific de unde se face referință la F69, dar s-ar putea să fie necesar să îl eliminăm din 1.4.4, având în vedere modificările din agenții utilizator.

joe-watkins comentat 26 aprilie 2018

Mulțumesc @alastc și post minunat - cum mi-ar fi dor de asta!?

Pentru o mai mare claritate, putem arunca o privire asupra acestor întrebări:

Pentru a testa/trece 1.4.4 Un autor/tester poate vizita un site într-un browser modern, apăsați cntrl + zoom browser la 200%. Dacă textul nu este trunchiat sau ascuns, trece 1.4.4? (reflow și spațierea textului se lansează pentru alte preocupări aici - foarte cool)

Dacă răspunsul la # 1 este da - deoarece Firefox și Safari moderne au ambele opțiuni pentru text doar în setările de zoom ale browserului, testerul ar trebui să dezactiveze acest lucru atunci când testează pentru 1.4.4 ?

F69 este menționat din eșecurile obișnuite pentru WCAG 1.4.4

@alastc Apreciez răspunsurile tale clare, bine gândite, dar aș vrea să distil asta pentru ca urșii obișnuiți să înțeleagă în sălbăticie. Web-ul/tehnologia a depășit puțin acest SC.

alastc comentat 26 aprilie 2018 •

Cu Reflow (1.4.10) în loc, redimensionarea textului completează acum nișele în care textul nu se scalează cu zoomul.

Deci, testul combinat pentru reflow, redimensionare text și spațiere text poate fi:

  • Setați fereastra browserului la 1280 px lățime.
  • Măriți la 400%.
  • Verificați conținutul și funcționalitatea sunt disponibile și nu are derulare orizontală (în limbile LTR).
  • Textul de verificare este cu cel puțin 200% mai mare.
  • Activați dimensiunea textului (de exemplu, cu un bookmarklet).
  • Anulați zoomul pe fiecare interogare media, căutând suprapuneri/conținut lipsă.

Există câteva nișe acolo, de ex. text vertical, text care variază în funcție de înălțimea ecranului, dar care ar trebui să surprindă majoritatea scenariilor.

Verificarea dimensiunii textului de 200% se datorează faptului că site-urile pot utiliza interogări media sau unități VW/VH pentru a preveni creșterea textului cu zoom. Dacă textul crește oarecum, verificați dacă dimensiunea calculată de browser în pixeli este de cel puțin 50% din valoarea implicită. (De exemplu, valoarea implicită de 10 px ar trebui să fie de cel puțin 5 px la 400%.)

Este suficient de distilat?

alastc comentat 26 aprilie 2018

Nu am vrut să spun că a fost ineficient pentru început, ci doar din perioada IE8 (

2008), Chrome (2009), ați putea spune că zoomul era disponibil pe scară largă.

Îl avem în continuare nevoie pentru scenarii în care reflow-ul nu este disponibil, cum ar fi dispozitivele mobile și tabelele.

patrickhlauke comentat 26 aprilie 2018

Înțeleg ce spui, dar, când consideri că este un guvern
agenția pentru care lucrez astăzi folosește IE-11

IE11 acceptă zoom-ul foarte bine, cu excepția cazului în care îmi lipsește punctul aici?

alastc comentat 26 aprilie 2018

Vă aud, am fost mari susținători ai schemelor de lichide la momentul respectiv:-)

Dar vremurile au trecut, cu suportul pentru interogări media (chiar și în IE) lucrurile s-au schimbat.

mraccess77 comentat 27 aprilie 2018

@Ryladog a scris „utilitatea 1.4.4, pentru mulți utilizatori, a durat pentru
destul de mult timp după ce WCAG 2.0 a devenit un standard. și apoi a avut o
renaștere surprinzătoare în mobil. "

Știu că spun asta întotdeauna - dar aproape în fiecare zi întâlnesc pagini care încă nu reușesc SC 1.4.4 cu zoomul browserului pe desktop din cauza multor probleme diferite. Deci, acest SC este încă foarte valoros astăzi și va continua să fie valoros atunci când este combinat cu SC 1.4.10.

WayneEDick comentat 27 aprilie 2018

De fapt, din perspectiva utilizatorului, 1.4.4 era aproape inutil.

Dacă vă calificați ca având un handicap de vedere scăzut din cauza acuității vizuale, acuitatea vizuală este mai mică de 1/3 din normal. În mod logic, s-ar putea crede că 333% ar fi extinderea minimă efectivă și ar fi corect. Lipsa refluxului a mutat-o ​​de la prea puțin la doar inutil.

WCAG WG a greșit 180%. Îmi doresc pentru o dată grupul de lucru să recunoască eșecul grav. De ani de zile oamenilor ca mine ni s-a spus că pur și simplu nu știm cum să folosim lupele de ecran corect sau că ar trebui să folosim braille sau că ar trebui să folosim doar cititoare de ecran. Tot ce cred a fost să neg faptul că WCAG WG a greșit teribil și a întârziat accesibilitatea pentru vederea slabă cu 8 ani. A fost o greșeală cumplită și a rănit oamenii. Oamenilor cu vedere scăzută li s-a făcut să simtă că este ceva în neregulă cu ei. Că erau doar incompetenți pentru că puteau folosi această asistență defectă.

Mi-aș dori ca grupul de lucru să își recunoască greșeala gravă.

patrickhlauke comentat 27 aprilie 2018

Știu că spun asta întotdeauna - dar aproape în fiecare zi întâlnesc pagini care încă nu reușesc SC 1.4.4 cu zoomul browserului pe desktop din cauza multor probleme diferite.

sunt aceste situații în care ar eșua 1.4.4 dar ar trece 1.4.10? sau oricum aceste pagini nu reușesc 1.4.10?

mraccess77 comentat 27 aprilie 2018

@ patrickhlauke Cred că 1.4.10 singur ar prinde multe dintre ele, dar nu toate situațiile. Având ambele SC este încă necesar în opinia mea.

@WayneEDick Sunt de acord că SC 1.4.4 nu a abordat nevoia principală de reflow - dar am eșuat SC 1.4.4 de multe ori în audituri atunci când există probleme care ar putea fi surprinse de acesta. Așa că a avut și are valoare, deși este limitată. Având în vedere că SC 1.4.8 se adresează refluxului, deși doar la 200%, aș spune că grupul de atunci a luat o decizie conștientă în jurul valorii de 1.4.4. În acel moment nu am fost invitat să fac parte din grup - așa că nu pot vorbi la nicio discuție pentru că din păcate nu am fost prezent.

alastc comentat 27 aprilie 2018

Aceasta este o tangentă destul de mare acum, dar voi spune că, deși nu făceam parte din grup atunci, pot vedea de ce 200% a fost luat ca cifră.

Oricine construiește site-uri web în anii 2000 vă poate spune că a fost dificil să creați un site atractiv cu o scară de până la 150%. Monoplia browserului unui bug IE6 a fost dificilă în 2004-8 și 200% îl împingeau. Până când am avut interogări media (acceptate), instrumentele nu erau disponibile pentru mai multe.

Oricum, lucrurile s-au schimbat, putem face actualizări mai regulate, să ne îndreptăm spre (sau în fața) pucului acum.

Revenind la problema ridicată, am putea economisi oameni destul de mult timp având un astfel de proces de test combinat.

Unde ar fi un loc bun pentru a pune asta?

DavidMacDonald comentat 27 aprilie 2018

În 2008, fără puncte de întrerupere, mărirea textului la 300% sau 400% sau chiar 200% fără derulare orizontală nu a fost pur și simplu ceva care ar fi obținut consens. Organizațiile mari de atunci nu ar fi permis niciodată întregul web să fie redus la tipul de aspect de bază pe care ar fi cerut-o. WCAG nu ar fi fost niciodată acceptat, nu ar fi fost obligat niciodată de lege și ar fi fost retrogradat în istorie ca un mare standard de advocacy pe care organizațiile academice și guvernele ar putea să-l aleagă după cum consideră potrivit.

mraccess77 comentat 27 aprilie 2018 •

@DavidMacDonald Înțeleg - de aceea am spus că este o decizie conștientă să plasezi 1.4.8 la AAA și 1.4.4 la AA. Deci suntem de acord. Punctul meu de vedere este că nu a fost prin omisiune, ci prin comisioane bazate pe factori pe care grupul a trebuit să-i pondereze în acel moment.

WayneEDick comentat 27 aprilie 2018

Nu vreau să relitig trecutul, dar uneori este important să recunoaștem magnitudinea unei erori, astfel încât să nu o mai facem.

Mărirea fără reflux nu a fost niciodată accesibilă. Pentru cei ca mine care foloseau televizoarele cu circuit închis pentru a citi tipărit pe hârtie, era singura modalitate de a citi. Așa trebuia să citești jurnale de cercetare. Cu toate acestea, reflow a devenit obișnuit cu Apple 2E. Tehnologia avea 30 de ani în 2008.

Interogările media au facilitat refluxul atunci când au devenit disponibile, dar un programator profesionist ar putea proiecta pagini care s-au mărit la 200% și au înfășurat cuvinte cu HTML 4, CSS 2 și ECMAScript. Nu a fost banal, dar nu a fost atât de greu. Tehnologia era acolo.

Grupul de lucru nu a înțeles importanța refluxului pentru grupul de utilizatori. Textul mărit cu reflow este destinat persoanelor cu pierderea acuității vizuale, deoarece braille-ul reîmprospătabil este la orbire. Este un mediu de citire static care acceptă citirea bazei de timp cu un cititor de ecran.

A fost exact ca eliminarea braille-ului reîmprospătabil din setul de instrumente de citire non-vizuală. WCAG ar fi trecut fără suport pentru braille reîmprospătabil? Problema profundă a fost că reflow-ul este la fel de important ca braille-ul reîmprospătabil, iar WG a ratat acest fapt critic.

Trecutul nu este important, dar în viitor sper ca GT să-și amintească acest adevăr. Ori de câte ori ne gândim la o excepție de la permiterea reflow-ului, amintiți-vă că eliminăm o caracteristică care este la fel de importantă ca și braille-ul reînnoit.

joe-watkins comentat 27 aprilie 2018 •

@alastc și gang Tnx! Ajutor sigur. Întrebare, totuși . vă rugăm să consultați .gifs-urile atașate - Ce zoom folosește unul pentru testarea 1.4.4 într-un browser care acceptă zoom numai text - activat sau dezactivat numai text?

1. Mărirea browserului Firefox cu numai text activat. Browserul a fost mărit la 200%, numai textul este mărit, navigarea principală se destramă.

interpretare

2. Mărire browser Firefox cu dezactivare numai text. Interogările media intră în acțiune și versiunea cu ecran mic a site-ului este vizibilă cu zoom de 200%.

În ambele cazuri folosesc zoom-ul browserului. Ambele oferă rezultate foarte diferite. În primul exemplu, aș considera că navigarea principală este un eșec de 1.4.4, iar al doilea nu aș face-o. (Deși încărcarea cognitivă a unui aspect complet diferit și eliminarea conținutului este un alt subiect) Aici intervine confuzia pentru designeri/dezvoltatori.

WG crede, deoarece funcționează în exemplul 2 de mai sus cu zoom normal, că CNN nu are un eșec de redimensionare a textului pe mâini?

Și dacă Reflow începe aici pentru a salva ziua pentru 1.4.4 în ceea ce privește primul exemplu cu numai text activat - cum și de ce?

mraccess77 comentat 27 aprilie 2018

WCAG este un standard funcțional. Rezultatul este că textul se redimensionează. Tot ce trebuie să existe este un mecanism. Există un mecanism. Nu toate mecanismele trebuie să se sprijine. În ceea ce privește designul receptiv - atâta timp cât vizualizarea receptivă are toate aceleași funcționalități și conținut, chiar dacă este sub un meniu hamburger sau este disponibil în alt mod, atunci este un permis. CNN poate avea alte probleme legate de redimensionare, cum ar fi antetele fixe aferente etc. - Nu pot spune dacă întregul site trece sau nu fără testare.

alastc comentat 27 aprilie 2018

Ce zoom folosește unul pentru testarea 1.4.4 într-un browser care acceptă zoom numai text

Nu așa funcționează WCAG, criteriul întreabă dacă este posibil ca utilizatorul să facă X (în acest caz X este mărirea dimensiunii textului, cu orice metodă).

Deci, dacă o cantitate rezonabilă de browsere (pe care utilizatorii le pot obține) acceptă zoom-ul general, atunci autorii (adică proiectanții și dezvoltatorii) se pot baza pe această caracteristică.

patrickhlauke comentat 27 aprilie 2018 •

1.4.4 spune că „textul poate fi redimensionat”, fără a specifica cum. indiferent dacă obțineți rezultate diferite, în funcție de modul în care un utilizator alege să redimensioneze, acest lucru este în general lipsit de importanță. ceea ce contează este: cel puțin unul dintre aceste moduri de redimensionare ajunge ca utilizatorul să poată redimensiona textul "până la 200 la sută fără pierderea conținutului sau a funcționalității"? și, bineînțeles, metoda ar trebui să fie ușor disponibilă pentru utilizatori în majoritatea agenților de utilizatori principali (ceea ce înseamnă, fără îndoială, că pe desktop, probabil că ne uităm la zoom pe toată pagina)

joe-watkins comentat 27 aprilie 2018

Mulțumesc @ mraccess77, @alastc, @patrickhlauke Super clar și uimitor RWD salvează ziua:) Aceasta este o bară foarte scăzută pentru a ajunge la dev . nu există legi care să spună că un autor nu ar putea ajunge dincolo de WCAG pentru a sprijini redimensionarea numai text, deși huh?

Și mi-a plăcut chat-ul lateral al celorlalți:) tnx din nou toate!

alastc comentat 27 aprilie 2018 •

De asemenea, nu vreau să litigiez din nou trecutul, dar dacă nu acceptăm constrângerile vremii, nu putem merge mai departe.

Este întotdeauna un echilibru între ceea ce este fezabil și ceea ce permite cel mai bun acces.

Mărirea fără reflux nu a fost niciodată accesibilă. reflow a devenit obișnuit cu Apple 2E. Tehnologia avea 30 de ani în 2008.

Pe web a început bine (de bază, dar accesibil în acest sens), dar când organizațiile au început să organizeze aspecte mai complexe, care erau optime pentru majoritate, aspectul reflow a suferit. Nu contează dacă a existat o tehnologie care a susținut-o acum 40 de ani, acum 15 ani web-ul nu o suporta pentru tipurile de machete dorite de organizații.

Interogările media au facilitat refluxul atunci când au devenit disponibile, dar un programator profesionist ar putea proiecta pagini care s-au mărit la 200% și au înfășurat cuvinte cu HTML 4, CSS 2 și ECMAScript. Nu a fost banal, dar nu a fost atât de greu. Tehnologia era acolo.

Îmi pare rău, dar nu este cazul. Am fost acolo, făcând astfel de machete.

Până în 2009, costul realizării „schemelor lichide” (asistență pentru interogare pre-media) a crescut până la 30% din costul total al proiectului și a crescut. Evident, a variat destul de mult, dar cerințele pentru companii, organizații caritabile și organizații guvernamentale pentru planuri/designuri mai complexe au făcut acest lucru foarte dificil, trecând de punctul de fezabilitate.

Grupul de lucru nu a înțeles importanța refluxului pentru grupul de utilizatori.

Nu pot vorbi la înțelegere la momentul respectiv, dar la acel moment am argumentat pentru unități relative și o redimensionare mai bună. Trebuie echilibrat cu fezabilitate, fie prin metode obișnuite, fie prin personalizare (mai dificil).

În mod ciudat, cred că mă voi cita din 2007 (de pe link-ul de mai sus), este atât de mult timp în urmă că îmi vine să citez pe altcineva!

există doar atât de multe modalități de amplasare a site-urilor în acest moment, cu excepția cazului în care modulul de aspect al CSS3 reușește să ajungă în curând, nu văd că agenții utilizator pot să-i dea seama pe toți.
Mă bucur că dimensiunea relativă a fontului a revenit în WCAG 2, dar Nu cred că este suficient.

(Nou accent.) În 2007, nu-mi amintesc exact ce trebuia să includă modulul CSS3, dar aș presupune că interogările media.

Pentru conţinut liniile directoare punem cerințele autorilor. Pentru a crește jocul, cerințele trebuie să funcționeze și cu browserele.