Accesibilitate WEB - solutii, propuneri, sfaturi

Deschid acest topic pentru a incerca sa vedem cum sta la ora actuala in Romania, in ceea ce ne priveste pe noi, webmasteri sau utilizatori de internet, problema accesibilitatii Web.

M-am bucurat sa vad ca s-a pomenit in cateva randuri, chiar si pe acest forum, si despre accesibilitatea WEB.
Eu sunt webmaster-ul catorva site-uri si sunt complet nevazator.

Voi incepe prin a spune ca exista o unealta pentru testare pagini foarte utila, deschide in Notepad un raport cu toate problemele care ar putea fi in cazul accesibilitatii, de asemenea si erorile semnalate de W3C in codul HTML 4.01 Transitional sau XHTML 1.1.
Link-ul urmator duce direct la kit-ul Test Page:
http://EmpowermentZo...om/tpgsetup.exe

Am inceput sa lucrez la un ghid pentru accesibilizarea site-urilor, probleme frecvente care exista pe net, dar sunt usor rezolvabile cu simple tag-uri HTML.
La urmatorul link este forma actuala a ghidului de accesibilizare siteuri:
http://www.pontes.ro...sibil/index.php
Important este ca acest ghid este lucrat de cineva care chiar foloseste cititorul de ecran Jaws, deci poate spune cel mai bine de ce anume este nevoie, fara a exagera in cerinte, fara sa fie nevoie de modificarea design-ului, solutii simple care nu vor avea efect vizual, ci doar auditiv.
Daca cineva doreste, putem efectua oricand o vizita pe un anume site si putem semnala cat de accesibil este, ce ar mai trebui pentru a fi ok. In site-ul unde se afla ghidul de mai sus, exista la sectiunea "Servicii", un serviciu gratuit in acest sens.

Pe marginea ghidului mai sus pomenit, am putea dezbate aici problema accesibilitatii, fapt care ar putea duce la imbunatatirea lui.

Sunt atatea site-uri care nu au nici macar un heading <H1>...<h6>, darmite toate imaginile cu un amarat de "alt". Iata ca am semnalat doua dintre cele mai importante minusuri care pot exista. Daca acestea doua ar fi indeplinite peste tot, putem spune ca 50% din accesibilitate ar fi indeplinita.
Dau ca exemplu site-ul EDU.RO, site care nu ar avea un cod greoi pentru cititoarele de ecran, dar care nu are acel heading, macar la inceput de continut, fapt care il face pe utilizatorul nevazator sa treaca folosind cursorul peste toate link-urile, nestiind de multe ori, mai ales daca e incepator intr-ale navigarii, unde incepe propriu-zis continutul aferent ultimului link pe care l-a accesat.

eu folosesc tot timpul h1 pana la h3-h4, "alt"-uri la poze si text ascuns in unele elemente ce au ca fundal o imagine cu text.
dar o fac mai mult din motive seo decat pt accesibilitate

Nici nu trebuie sa fie mai multe nivele de heading-uri, e suficient si unul plasat bine, adica la inceputul continutului specific paginii respective.
Pentru asta, daca cineva chiar nu vrea sa puna heading in pagina din cine stie ce motive, exista mai nou, Yahoo Mail foloseste deja, un atribut "ROLE". Acest atribut, adaugat la tagul <div> sau <p> care deschide  partea cu continutul central al paginii, sub forma <DIV ROLE="main">, face ca utilizatorul de screen-reader Jaws sau Windows Eye sa poata ajunge direct acolo folosind tasta ";". La heading ajunge folosind tasta "h". ROLE nu influenteaza nici macar cat heading-ul designul, e ceva si mai simplu, doar ca va aparea ca eroare de validare W3C.

Mda, trebuie să recunoscă faptul că nu prea mi-am pus problema asta. Însă este o discuție bine venită. Există ceva particularități în cazul motoarelor de căutare din punctul de vedere al accesibilizării? De exemplu www.google.ro sau site-ul meu www.xirincs.ro ca să-i fac un pic de reclamă. Pentru că ele conțin doar o listă de link-uri. Heading-urile și alt-urile sunt într-adevăr utile atât din punctul de vedere al optimizării pentru motoarele de căutare (seo) dar și pentru un utilizator obișnuit care își poate da seama imediat despre ce este pagina respectivă cu toate că H1 este cam mare. Altă întrebare este cum vă descurcați cu fișierele flash? Cu cele video... cred că este o problemă, dar cele audio? Dar cu fisierele rss/atom? Sunt mai simple și ar trebui să poată fi citite mai ușor de acele cititoare de ecran. Despre care nu prea știu nimic, habar n-am cum funcționează și cred că ar fi util să ne dai mai multe informații. Însă am văzut pe undeva un program care transforma în podcast un articol rss/atom adică îl citea; însă probabil nu și dacă era scris în limba română; chestia asta cred că ar putea fi implementată de multe site-uri care livrează informația și în această formă de flux xml. Și ultima întrebare pentru moment, ma interesează punctul vostru de vedere privind blogging-ul și microblogging-ul. Am pus toate aceste intrebări pentru că au legătură cu ceea ce fac eu și poate voi reuși să folosesc cândva unele dintre ideile pe care le voi afla aici.

Edited by xiro, 04 August 2009 - 00:11.

Nu prea înțeleg întrebarea aceea cu particularitatea în cazul motoarelor de căutare gen Google sau site-ul tău...
Oricum, atât Google, cât și site-ul menționat de tine sunt accesibile, nu văd ce ar putea avea neinteligibil pe ele, al tău, cel puțin pe prima pagină, nu are heading-uri, nici nu văd la ce bun ar fi deoarece este genul de site pe care și nevăzătorul care abia a început să navigheze pe internet cu Jaws (screen-reader-ul folosit la noi în proporție de 99%) ar putea să-l citeasca în totalitate fără probleme.
Deci, să reiau problema heading-ului: acel măcar unul, este bun în cazul site-urilor cu un conținut mare, cu zeci de link-uri, gen ziare online, unde se poate ajunge foarte ușor la începutul articolului doar prin apăsarea unei taste care este prevăzută în program ca scurtătură pentru heading-uri.
Google folosește heading la fiecare rezultat găsit, adică la titlul paginilor, acestea fiind plasate într-o listă de tip <ol>, deci două avantaje, pe lângă heading, pentru screen-reader și găsirea automată a listei cu altă scurtătură.
Nu știu cum aș putea explica nivelul la care se situează în prezent tehnologia de acces, mă refer acum la screen-readere...
Este atât de avansată încât se poate face cam orice, din moment ce eu, nevăzător fiind, scriu aici în forum fără probleme, iar SoftPedia e imens în conținut, oricare pagină având câteva sute de link-uri. Cine se descurcă bine în navigatul pe internet, nu depinde în mod special de folosirea unora sau altora dintre tehnicile de care vorbeam eu în ghid, dar acelea ușurează enorm navigatul și îi lasă și pe cei începători sau cu abilități mai puțin dezvoltate să găsească informație utilă pe internet, să vă viziteze site-urile...

În legătură cu implementarea pe site-uri a unor sisteme care să transforme articole în audio... hm... este absolut inutilă opțiunea pentru nevăzători, probabil utilă pentru miopii care nu folosesc cititoare de ecran și au ca opțiune, după ce se chinuie câtva timp să găsească ceva interesant, să i se citească articolul automat direct acolo...

În legătură cu blogging-ul... ce pot să spun, este ok, nu văd ce părere să am, este tot un site ca toate site-urile, nu văd ce aș putea spune despre el... Orice există pe net este vizibil pentru cititorul de ecran ca și pentru ceilalți. Bineînțeles că nu va citi un screen-reader ce apare intr-o secvență video dar... e ok atâta vreme cât mai este un sonor ori, dacă e într-o pagină un filmuleț, măcar să se descrie cât de cât ce ar conține, pentru a nu se pierde din contextul site-ului, în caz că filmul are vreo relevanță în asta. Eu de exemplu caut destul de mult și pe YouTube fără probleme.
Flash-urile însă este marea problemă. Nu contează dacă se inserează un flash cu o reclamă sau altceva de genul acesta pe o pagină, poate fi ignorat ușor, contează mult când totul este realizat flash, butoanele de meniu etc., atunci... sunt reale probleme de navigat. Din fericire, sunt puține site-uri de acest fel, construite doar în flash, iar cine știe cât de cât ce înseamnă internetul și un site profesional... sigur nu va alege ca opțiune strict doar flash-ul. În caz că cineva vrea să facă impresie vizuală cu ceva foarte dinamic în flash, ar fi totuși utilă o mică variantă text, cel puțin cu esențialul... asta în caz că are vreo importanță site-ul și dorește să se adreseze câtor mai mulți.


Explic în continuare puțin cum se utilizează un cititor de ecran pe internet
La o simplă navigare cu săgeata în jos, cititorul va lua la rând tot ceea ce găsește pe pagină, în ordinea în care este dispus codul sursă. Anunță când dă de un link, când dă de o imagine, de un heading, de o listă etc.. De aceea, cel mai des, cum meniul este sus pe pagină sau în partea stângă, în codul sursă găsindu-se înaintea conținutului unei pagini anume, e mai greu de găsit conținutul, fiind necesară parcurgerea treptată a tuturor elementelor până la acesta. Existând însă un heading la începutul conținutului, se va putea ajunge direct la el cu o tastă scurtătură pentru heading-uri. Sunt tot felul de metode de navigat rapid, se pot pune marcaje etc., dar eu acum vorbesc de modul simplu, cam cum ar folosi cineva mai neavizat, mai începător.
Poate pe parcurs, dacă vor fi curioși, voi detalia mai amănunțit cum citește vocea sintetică diferite elemente de pe paginile WEB, este foarte greu să îți faci idee cum se lucrează, fiind din afara problemei.
Oricum, tehnologia de acces s-a dezvoltat enorm, de exemplu există pentru Firefox o extensie Web Visum care descifrează codurile Kafka pentru ca un nevăzător să își poată crea de unul singur un cont pe Yahoo sau chiar aici pe forumul SoftPedia.

1) Să spui că "h1 e prea mare" e cel puțin dubios. Deaia este css, care pentru cititor și pentru boți e invizibil.
2) SEO și cititoarele au nevoie de același lucru: marckup corect.
3) Chiar dacă alegi Flash-ul nu înseamnă că nu poți fii accesibil. Flash are de mult facilități în acest sens și pe lângă asta e și destul de ușor să servești o pagină statică cu tot conținutul în funcție de user agent, nefiind nevoie de css. Pe o pagină de prezentare trebuie doar o pagină statică, pentru o pagină dinamică oricum se presupune că informația vine spre Flash ca XML și de aici până la XHTML nu mai e decât XSLT-ul, de cele mai multe ori banal.
4) Meniul se poate poziționa după conținut (în HTML) dar afișa oriunde (folosind CSS). Există foarte multe tutoriale și articole pe această temă. Și din punctul ăsta de vedere SEO și cititoarele merg mână în mână.

Vroiam să te întreb dacă cititorul se înțelege bine cu diacriticele, dar văd că deja le folosești, ceea ce e foarte bine.

Vreau să întreb totuși dacă există standarde legate de adăugarea unor clase sau id-uri elementelor principale ale paginii (conținut, meniu, footer) pe care cititorul le recunoaște și la care se poate sări ușor. Ar fi foarte util și ar ajuta mult, cu condiția ca toată lumea să adere la standard. Dacă ar fi după mine probabil aș include așa ceva în următoarele specificații XHTML.

Într-adevăr, CSS-ul nu încurcă cititorul de ecran, oricât de mare sau mic ar fi setat un <H1>, orice style ar avea, mie mi se citește tot cam in felul următor când dau de el: "Heading Level 1 - Bine ați venit!"
În prezent nu se mai folosește <b>, <i>, <u>, <font> - sunt afișate ca erori pentru standardele de accesibilitate, chiar dacă totul e OK și nu încurcă nici cititorul, nici Validatorul W3. E mai simplu să existe pentru toate formatările clase și ID-uri CSS. Acuma... dacă eu vreau neapărat să aflu cât de mare este un text, de exemplu acel heading de care pomeneam mai sus, sunt funcții în programul cititor de ecran care îmi permit cam orice, chiar printr-o comandă să văd și atributele HTML folosite în zonă, fără să mai deschid codul sursă. Vă spun că este foarte avansat Jaws-ul.

Diacriticele sunt OK în funcție de cititor, noi în România folosim Jaws for Windows, este cel mai dezvoltat, permite absolut orice, chiar și programare în interiorul lui, scripting pentru acțiuni diverse pe care să le facă în locul tău, deci ceva serios, cu tot cu "while", "if" etc...
Pe site-urile la care eu sunt webmaster folosesc diacriticele cu UTF8, acestea sigur nu vor avea probleme în Jaws (cel folosit în proporție de 99,9%). Cititorul de ecran pe care îl folosim pe telefon mai are mici probleme, dar și pe acestea le-am rezolvat printr-un work around, vezi:
http://www.pontes.ro...opic.php?t=1907

În legătură cu împărțirea de care vorbeai a paginii la nivel semantic, este pe cale de a se impune, prin presiunile pe care le fac unii, știu că și cineva de la IBM, cei de la Yahoo Mail au deja: Landmark-urile.
Este vorba de atributul ROLE pus la orice tag HTML, atribut care poate fi doar de câteva feluri: ="banner", ="Search", ="navigation", ="main", =complementary", ="application" și ="contentinfo".
Dacă ne uităm la orice pagină, nu știu dacă ar putea exista și alte tipuri de conținut, decât cele care reies din parametrii de mai sus ai atributului ROLE. Cititorul de ecran, care citește direct sursa HTML pentru a da feedback, va găsi aceste marcaje cu ROLE, simplu folosind tasta ";" (punct și virgulă), browser-ul va ignora ROLE, neavând nici o chestie de interpretat din el. Ca să fie mai clar, link-ul următor duce direct la capitolașul despre landmark-uri din ghidul pe care am început să îl scriu:
http://www.pontes.ro...ex.php#landmark
Toată problema cu ROLE, deși ar fi, după părerea mea, cea mai bună împărțire a paginilor este că va apărea ca eroare formală de validare. Însă... nu știu câte site-uri sunt valide din punct de vedere HTML 4.01 sau XHTML 1.1... deci, dacă ar apărea pe lângă cele câteva 10 încă două-trei... nu ar fi mare lucru, mai ales că sunt absolut formale și nu au nici o influență distructivă, indiferent de browser IE, Firefox, Safari etc..
Eu, cel puțin la trei dintre site-uri, cele care se adresează în mai mare măsură nevăzătorilor, am pus astfel de landmark-uri, chiar dacă acum la validare sunt singurele erori și ar strica putin imaginea: www.pontes.ro www.ldv.ro www.anrcluj.ro

Mi se pare super tare topicul. Felicitări pentru inițiativă! Am și eu câteva întrebări:
- cât de bine citește jaws textul în română? Adică... Cititoarele „clasice” text2speech (cum ar fi cel din windows, de ex) au un accent cel puțin dubios.
- cât de bine se descurcă jaws cu javascript? Dacă injectez cu javascript atributul ROLE, va fi vizibil? ROLE nu e valid deoarece se vroia introdus în xhtml 2.

Nu cred că sunt probleme nici cu Javascript, cel puțin nu am văzut vreun exemplu să știu despre ce e vorba.

Pentru a clarifica puțin treaba, Jaws este cititorul de ecran, screen-reader-ul, iar restul sunt Sintetizatoarele care transpun audio ceea ce i se dă de către cititorul propriu-zis. Printre aceste sintetizatoare este și cel de care vorbeai... dar... acela nu este folosit de nimeni, Windwos l-a pus doar pentru a îndeplinii niște obligații, vă imaginați ce amenzi ar fi luat dacă nu punea, măcar formal, câte ceva la dispoziție pentru nevăzători. Jaws acceptă multe sintetizatoare, noi folosim Eloquence cu italiana care fonetic seamănă cu româna și Wintalker, un sintetizator gratuit pentru țările din este - ambele sunt ok din punct de vedere al diacriticelor. Așa, just for fun, Jaws costă $1095.

ROLE este prevăzut pentru XHTML2, dar... merge OK în orice situație pentru că Jaws, după cum am spus, citește sursa și, dacă tot dă de el, îl și interpretează.

Cineva întreba mai sus dacă merge cu Javascript screen-reader-ul. De asemenea era vorba de faptul că ROLE nu este validat.
Mai jos, printr-un exemplu arăt că ambele probleme sunt OK, se poate atât valida HTML-ul, cât și Javascript-ul e ok, soluția stând chiar în el.

Așadar, dacă este vorba de un site valid, la care afișarea erorilor nu ar da bine, există următoarea tehnică prin care landmark-urile, ROLE rămâne la fel, doar că validatorul nu detectează nici o eroare, atributul fiind inserat în pagini cu ajutorul unui sistem Javascript, după cum se arată în continuare.
Mai întâi trebuie inclusă următoarea secvență în header-ul paginilor:

<script TYPE="text/javascript" SRC="landmarks.js"> </SCRIPT>

Secvența de mai sus se referă la un fișier "landmarks.js", , fișierul poate fi creat manual cu un editor Notepad în care să dați paste la următoarea secvență de cod java script:

(ÎNCEPUT COD Javascript)
function setRoleAttribute(id, rolevalue) {
if(document.getElementById(id)) {
document.getElementById(id).setAttribute("role", rolevalue);
}
}
function setAriaRoleElementsById() {
setRoleAttribute("navigation", "navigation");
setRoleAttribute("main", "main");
setRoleAttribute("complementary", "complementary");
setRoleAttribute("contentinfo", "contentinfo");
setRoleAttribute("application", "application");
setRoleAttribute("banner", "banner");
setRoleAttribute("search", "search");
}
window.onload=function(){ setAriaRoleElementsById(); }
(SFÂRȘIT COD Javascript)

Având toate acestea, nu mai trebuie decât folosirea atributului ROLE cu sinonimul ID creat.

Codul HTML:
<DIV ID="navigation">Meniul principal</DIV>

frumos, nu m-am gandit la javascript
m-am pus si eu sa adaug 'role" la niste teme wp.

e mai simplu cu jquery, ca si asa il folosesc oricum:

  jQuery("#tabs").attr("role","navigation");
  jQuery("#mid-content").attr("role","main");
  jQuery("#sidebar").attr("role","complementary");
  jQuery("#searchform").attr("role","search");


dar contentinfo ce ar trebui sa fie?

Edited by unu, 05 August 2009 - 00:25.

contentinfo este de obicei partea de jos a paginilor, footer-ul, partea cu webmaster, designer, site realizat de, sigle etc..
Daca te uiți în Capitolul despre Landmark-uri pe care l-am scris în ghidul de care vorbeam în primul post din acest topic, o să vezi foarte exact cum ar trebui distribuite pentru a deveni treaba inteligibila.
Dacă chiar ai de gând să incluzi în vreun site această împărțire la nivel semantic, dă-mi și mie te rog adresa, sa scriu pe forumul Pontes, acolo unde intră mulți nevăzători, să vadă lumea care ar fi primul site din România cu așa ceva, excluzându-le pe cele de care mă ocup eu în prezent. Ar deveni o chestiune istorică în ceea ce privește accesibilitatea, mai ales când vor avea foarte multe așa ceva, cel puțin după trecerea la web-ul semantic.

Pun mai jos un fragment scris pe forumul Pontes în care explicam succint pentru utilizatorii nevăzători de internet ce ar fi cu aceste landmark-uri. Cineva cerea detalii în calitate de utilizator Jaws:
""""
Este vorba de o impartire a paginii la nivel semantic, adica o impartire pe tipuri de continut. Practic ce tipuri de sectiuni poate avea o pagina? - Meniuri, continut central, informatii despre pagina (cine a creat-o etc.), camp pentru cautare in site si altele, in total au fost alese 7 pe care le prezint mai jos.

Pe site-ul Pontes, prima pagina sunt urmatoarele landmark-uri la care se ajunge cu Jaws 10 folosind ";" (punct si virgula, tasta de dupa "l", indiferent de limba tastaturii):
Search Landmark - semnaleaza sectiunea cu campul de cautare in site;
Navigation landmark - semnaleaza inceputul meniului principal;
Complementary landmark - zona aceea cu datele meteo din Cluj-Napoca si Bucuresti;
Main landmark - inceputul continutului central al paginii principale, acolo unde se zice "Bine ati venit", si noutatile;
Un al doilea Navigation landmark - inceputul meniului rapid, deci si acesta este tot un Navigation.
Content Info landmark - partea de jos unde se spune webmaster, designer, sunt sigle etc..
Pe celelalte pagini lipseste al doilea Navigation landmark, stim ca doar pe prima pagina avem si un Meniu rapid.

Pe langa cele mentionate mai sus, ar mai putea fi:
Banner landmark - prin acesta semnalandu-se partea de "antet" a paginilor, banner, sigla etc.. Am renuntat deocamdata la includerea lui pe pontes, aceasta sectiune gasindu-se chiar sus si... nu are atata importanta pentru nevazatori, dar se poate usor include in caz ca cineva doreste in mod expres.
Application landmark - aici ar putea fi o sectiune cu vreo aplicatie, de exemplu butoane prin care sa se dea play la vreun filmulet, ori ceva script care calculeaza ceva, chestii dinamice cu butoane, mini-programe in cadrul paginilor.

Spre a mai exemplifica, la Yahoo Mail exista mai multe landmark-uri, dintre care unul foarte util ar fi Main landmark, la el se ajunge cu cateva apasari ale tastei ";" (punct si virgula); cei de la Yahoo Inc au pozitionat acest Main landmark chiar la inceputul textului unui mail, ceea ce usureaza enorm navigatul de catre nevazator, inainte orice am fi facut, tot trebuia sa trecem cu cateva sageti pana la textul propriu-zis.

Daca in timp s-ar impune aceasta impartire a paginilor site-urilor... am reusi sa navigam mult mai usor, practic am stii din start in ce fel de parte a unei pagini ne aflam, nu am mai risca sa confundam continutul central (main) cu meniul (navigation) sau, si mai posibil, cu partea care da detalii despre site (content info)..

Vad ca Freedom Scientific da o mare insemnatate acestui tip de impartire... Daca inainte Jaws anunta la incarcarea unei pagini automat numarul de heading-uri si numarul de link-uri, mai nou, inainte de cele doua informatii anunta numarul de landmark-uri aflate in pagina curenta.
"""""

well deocamdata am adaugat "role" la 2 teme wp la care lucrez  deja de cateva luni si care au devenit destul de cunoscute - Arclite si Fusion

Edited by unu, 05 August 2009 - 01:27.

Pentru ca pe acest forum intră multă lume, mai postez din când în când soluții conform subiectului.
Una dintre problemele frecvente care pot apărea este cea a edit-box-urilor din formulare.
Jaws for Windows știe să anunțe textul cel mai apropiat de un <INPUT...> ca fiind indicația de completat pentru acesta, însă nu întotdeauna se potrivește, iar unele screen-readere, precum Nuance Talks, folosit pe telefoanele mobile cu Symbian, nu vor spune decât că acolo se află un câmp de editare, fiind posibil ca nevăzătorul să nu știe ce trebuie scris în el. Soluția este eticheta <LABEL>, suficientă pentru a nu mai exista posibile neplăceri.
Codul HTML ar fi:
<LABEL FOR="id-câmp">Numele dvs</LABEL>
<INPUT ID="id-câmp" TYPE="text">
Pe primul rând este definită eticheta pentru câmpul de editare cu ID-ul "id-câmp"; având această etichetă, screen-reader-ul va citi cu siguranță că în acel câmp de editare trebuie scris un nume.