Am citit un articol despre accesibilitate care a aparut in urma cu doua zile:
http://www.marcozehe.de/2013/09/07/why- ... is-matter/
Mi s-a parut interesant. (si comentariile).
Este in engleza.
Articol despre accesibilitatea web
Moderator: Manu
-
Manu
- General de divizie
- Mesaje: 4120
- Membru din: 02 Feb 2007, 01:15
- Localitate: Cluj-Napoca
- Contact:
Trebuie sa vedem exact ce si cum prezinta intr-o pagina acea extensie.
Se pare ca vor fi necesare astfel de unelte cu noua directie pe care o apuca in prezent site-urile.
Cu timpul site-urile vor fi defapt niste aplicatii complexe incarcate de la distanta dar dinamice local, deja pot fi gasite tree view-uri si tot felul de elemente de interfata grafica pe care le credeam in trecut posibile doar in aplicatii desktop.
Nu stiu cat va mai rezista JAWS sa afiseze continutul in modul virtual, cred ca va fi tot mai mult nevoie de interactiune directa cu elementele, cam ca in cazul aplicatiilor desktop. Nu stiu daca au apucat-o pe o cale buna si cu Virtual Ribbon. Cred ca e o problema destul de mare ca nu se poate altfel si ca se incearca solutii prin virtualizare peste tot.
Un exemplu mic de virtualizare care e utilizat des de nevazatori, dar care nu prea e bun pentru ca nu prezinta informatii actualizate este Tray Icon de la Insert + F11. Multi nu inteleg ce se intampla si se mira de ce atunci cand Dropbox se sincronizeaza, sa zicem, procentele raman pe loc, apoi cand descopera ca apasand Escape si iar F11 si tot asa se poate urmari evolutia lucrurilor, devin nemultumiti de munca depusa.
Se pare ca vor fi necesare astfel de unelte cu noua directie pe care o apuca in prezent site-urile.
Cu timpul site-urile vor fi defapt niste aplicatii complexe incarcate de la distanta dar dinamice local, deja pot fi gasite tree view-uri si tot felul de elemente de interfata grafica pe care le credeam in trecut posibile doar in aplicatii desktop.
Nu stiu cat va mai rezista JAWS sa afiseze continutul in modul virtual, cred ca va fi tot mai mult nevoie de interactiune directa cu elementele, cam ca in cazul aplicatiilor desktop. Nu stiu daca au apucat-o pe o cale buna si cu Virtual Ribbon. Cred ca e o problema destul de mare ca nu se poate altfel si ca se incearca solutii prin virtualizare peste tot.
Un exemplu mic de virtualizare care e utilizat des de nevazatori, dar care nu prea e bun pentru ca nu prezinta informatii actualizate este Tray Icon de la Insert + F11. Multi nu inteleg ce se intampla si se mira de ce atunci cand Dropbox se sincronizeaza, sa zicem, procentele raman pe loc, apoi cand descopera ca apasand Escape si iar F11 si tot asa se poate urmari evolutia lucrurilor, devin nemultumiti de munca depusa.
Errare humanum est, sed perseverare diabolicum...
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
De acord, interesant articol. E eterna batalie in accesibilitate, modul corect de a face treaba, cu api-uri, si modul hackish, folosind chestii nonstandard, facute pentru altceva, dar cu flexibilitate mai mare. Exact cum e si pe desktop cu MSAA versus video intercept.
Altfel, bine ca stiu, cand nu imi merge un site, trebuie sa incerc si cu ChromeVox. Problema e ca parca vad ca are doar suport sapi, si nu voi putea folosi eloquence...
@Manu, intr-adevar. Nu mai stiu daca s-a spus pe aici, yahoo deja si-a refacut interfata de mail. Te misti intre mailuri cu sageti si citesti continutul cu tab, ca in outlook express. Asta e un caz special, in care yahoo nu doar ca au facut o interfata moderna, ci s-au chinuit s-o faca si accesibila. Din pacate, accesibilitatea acestor aplicatii web nu se compara inca cu cele desktop. Tot Marco Zehe avea un articol in care arata ce greoi se misca yahoo mail.
Altfel, bine ca stiu, cand nu imi merge un site, trebuie sa incerc si cu ChromeVox. Problema e ca parca vad ca are doar suport sapi, si nu voi putea folosi eloquence...
@Manu, intr-adevar. Nu mai stiu daca s-a spus pe aici, yahoo deja si-a refacut interfata de mail. Te misti intre mailuri cu sageti si citesti continutul cu tab, ca in outlook express. Asta e un caz special, in care yahoo nu doar ca au facut o interfata moderna, ci s-au chinuit s-o faca si accesibila. Din pacate, accesibilitatea acestor aplicatii web nu se compara inca cu cele desktop. Tot Marco Zehe avea un articol in care arata ce greoi se misca yahoo mail.
Vortex Website
Maximum de confort, cu minimum de efort.
Maximum de confort, cu minimum de efort.
Re: Articol despre accesibilitatea web
Mai degraba cearta decat batalie. Ma gandeam si eu ca e o batalie, apoi mi-am dat seama ca din urma ei ar trebui sa avem noi de castigat, insa tocmai asta este miezul discutiei, ca in ultimii ani nu prea am mai castigat multe in acest domeniu.
Iata si o reactie potrivnica trimisa pe email la acel articol:
I was a little divided on responding to this, but since you posted this here, I guess I will here as well.
Overall, I found the post to be incredibly dogmatic in its adherence to 1990s thinking around accessibility and was honestly surprised at the overall tone of disrespect. As background, I've done QA, development, and usage of both browser and screen reader in my career for multiple companies.
As the big platforms moved towards accessibility API's starting with MSAA in 95, NSAccessibility in 03 (Jaguar), and UI Automation (05ish Vista),, it has always been a challenge to describe any arbitrary user interface in very narrow terms funneled through one interface that requires a hard-coded "role" and the overall complexity of getting things to work. I remember, for example, looking at the IAccessible implementations for raw win32 controls and thinking how incredibly unmaintainable it all is. It brings a high cost to developing applications for accessibility and is no wonder why all of your favorite screen readers out there today all incorporate a myriad of hacks and scripts/plugins to deal with every app on an individual level. It is also, why certain browsers, still have no or very poor support for very mainstream platforms like Mac OS X despite multiple attempts over the years.
As IAccessible2 grew and grew to try and describe the web, it was pretty much one browser that supported these interfaces (i.e. they actually didn't get consensus from the other major players like IE). Concurrently, Jaws continued to use IExplorer (the COM interface) and do their own calculations for name, role, and state (the basic components of the "standard"). Since the "standard" in spec form is available to everyone, no one from the user population really had a problem since Jaws and everyone else could easily implement it (from both the perspective as a DOM interpreter and client). Yes, as in all software there are bugs, but Jaws and anyone who interprets the DOM can do so and get it right in terms of standards. Rather than having the browser do it, it simply gets delegated up the chain to Jaws and why that is an issue perplexes me. Both are data structures (trees) and expose similar amounts of information; in the case of accessibility, there's actually less information available. Yes, it does ease the burden of a screen reader vender in that they can use one API and be done with it, but in practice, Jaws and every other screen reader out there use a variety of sources to achieve the goal of providing the best user experience possible. If the accessibility API is slower, well, then doesn't it make sense to use the DOM directly? If your favorite new tag or attribute is only available through the DOM , shouldn't a screen reader user have the equal right to access it like anyone else? As another app on a platform, why should you only use one set of API's and not another? That's not a requirement we impose on any other set of developers is it?
As for developer friendliness, there's pretty much no question in my mind who wins out. ChromeVox, written in javascript, takes a developer from their code (as exposed in a DOM tree, event handlers, and javascript), directly into more javascript and directly into either text to speech or braille.
Contrast this with the accessibility stack. Let's take Windows for simplicity. You first go from the DOM, into a render tree. Then, the render tree gets transformed into an accessibility tree. As you follow along in C++ (both steps above), you will dig through lots of browser-specific code and eventually land in Windows land. At that point, there are lots of custom interfaces like IAccessible2 and specific ones dealing with specific controls. Ok, now what? Well, it travels throughout he OS into what is in most cases (except for NVDA) a blackbox. So, suppose we take NVDA. There's an injected DLL in C++ where NVDA does some more transformations. Finally, the "stuff" of the DOM arrives in python land and NVDA does some more processing on the info received.
As a developer, I like option one thank you very much. I won't list all of the reasons why, but at the very least, I can do a quick fix for either my webpage or ChromeVox and test it out before Chrome or FF even finishes building.
Funny thing is, I don't have a problem with either solution fundamentally and I think for the health of accessibility, both should be pursued for different reasons.
- David
Iata si o reactie potrivnica trimisa pe email la acel articol:
I was a little divided on responding to this, but since you posted this here, I guess I will here as well
.Overall, I found the post to be incredibly dogmatic in its adherence to 1990s thinking around accessibility and was honestly surprised at the overall tone of disrespect. As background, I've done QA, development, and usage of both browser and screen reader in my career for multiple companies.
As the big platforms moved towards accessibility API's starting with MSAA in 95, NSAccessibility in 03 (Jaguar), and UI Automation (05ish Vista),, it has always been a challenge to describe any arbitrary user interface in very narrow terms funneled through one interface that requires a hard-coded "role" and the overall complexity of getting things to work. I remember, for example, looking at the IAccessible implementations for raw win32 controls and thinking how incredibly unmaintainable it all is. It brings a high cost to developing applications for accessibility and is no wonder why all of your favorite screen readers out there today all incorporate a myriad of hacks and scripts/plugins to deal with every app on an individual level. It is also, why certain browsers, still have no or very poor support for very mainstream platforms like Mac OS X despite multiple attempts over the years.
As IAccessible2 grew and grew to try and describe the web, it was pretty much one browser that supported these interfaces (i.e. they actually didn't get consensus from the other major players like IE). Concurrently, Jaws continued to use IExplorer (the COM interface) and do their own calculations for name, role, and state (the basic components of the "standard"). Since the "standard" in spec form is available to everyone, no one from the user population really had a problem since Jaws and everyone else could easily implement it (from both the perspective as a DOM interpreter and client). Yes, as in all software there are bugs, but Jaws and anyone who interprets the DOM can do so and get it right in terms of standards. Rather than having the browser do it, it simply gets delegated up the chain to Jaws and why that is an issue perplexes me. Both are data structures (trees) and expose similar amounts of information; in the case of accessibility, there's actually less information available. Yes, it does ease the burden of a screen reader vender in that they can use one API and be done with it, but in practice, Jaws and every other screen reader out there use a variety of sources to achieve the goal of providing the best user experience possible. If the accessibility API is slower, well, then doesn't it make sense to use the DOM directly? If your favorite new tag or attribute is only available through the DOM , shouldn't a screen reader user have the equal right to access it like anyone else? As another app on a platform, why should you only use one set of API's and not another? That's not a requirement we impose on any other set of developers is it?
As for developer friendliness, there's pretty much no question in my mind who wins out. ChromeVox, written in javascript, takes a developer from their code (as exposed in a DOM tree, event handlers, and javascript), directly into more javascript and directly into either text to speech or braille.
Contrast this with the accessibility stack. Let's take Windows for simplicity. You first go from the DOM, into a render tree. Then, the render tree gets transformed into an accessibility tree. As you follow along in C++ (both steps above), you will dig through lots of browser-specific code and eventually land in Windows land. At that point, there are lots of custom interfaces like IAccessible2 and specific ones dealing with specific controls. Ok, now what? Well, it travels throughout he OS into what is in most cases (except for NVDA) a blackbox. So, suppose we take NVDA. There's an injected DLL in C++ where NVDA does some more transformations. Finally, the "stuff" of the DOM arrives in python land and NVDA does some more processing on the info received.
As a developer, I like option one thank you very much
. I won't list all of the reasons why, but at the very least, I can do a quick fix for either my webpage or ChromeVox and test it out before Chrome or FF even finishes building.Funny thing is, I don't have a problem with either solution fundamentally and I think for the health of accessibility, both should be pursued for different reasons.
- David
Stiu si eu daca n-am avut de castigat... E drept ca nu a fost o competitie directa intre metode, dar ambele au avansat.
Metoda 1, aia cu DOM, e folosita si de NVDA in firefox, chiar mai bine decat jaws. Exista posibilitatea navigarii de calitate pe web pe windows fara cumpararea unui screen reader. Chrome si, mai nou, Opera au introdus accesibilitate.
As incadra aici si talks pe symbian, ca tot ceva cu javascript facea, si Talkback pe android cu browser-ul default.
Pentru metoda 2, e chiar ChromeVox si FireeVox, tool-uri care se leaga direct la browser si, vorba aluia din mail, vor fi mult mai usor de tinut up to date. Eu tind sa fiu de acord cu el, api-urile astea complicate sunt greu de intretinut si nici nu prea aduc bani, asa ca e mai simplu sa te legi direct la dom, cu toate riscurile aferente.
Metoda 1, aia cu DOM, e folosita si de NVDA in firefox, chiar mai bine decat jaws. Exista posibilitatea navigarii de calitate pe web pe windows fara cumpararea unui screen reader. Chrome si, mai nou, Opera au introdus accesibilitate.
As incadra aici si talks pe symbian, ca tot ceva cu javascript facea, si Talkback pe android cu browser-ul default.
Pentru metoda 2, e chiar ChromeVox si FireeVox, tool-uri care se leaga direct la browser si, vorba aluia din mail, vor fi mult mai usor de tinut up to date. Eu tind sa fiu de acord cu el, api-urile astea complicate sunt greu de intretinut si nici nu prea aduc bani, asa ca e mai simplu sa te legi direct la dom, cu toate riscurile aferente.
Vortex Website
Maximum de confort, cu minimum de efort.
Maximum de confort, cu minimum de efort.
Sincer sa fiu, eu nici nu stiu ce sa zic, fiindca mai degraba zic ca aamandoi au dreptate intr-un fel.
Este ceva asemanator cu problema accesarii unui atribut al unui obiect in mod direct sau prin intermediul unei metode care asigura o interfata standard, si care eventual asigura ca acel atribut nu este modificat etc.
In esenta idea accesarii printr-o interfata standard este buna, fiindca chiar daca clasa este modificata iar acel atribut isi schimba denumirea, el va putea fi accesat in continuare prin aceeasi metoda standard, asa ca stabilitatea este asigurata.
Pe de alta parte accesarea directa a atributului poate fi mai rapida si uneori asta conteaza.
In domeniul accesibilitatii viteza chiar conteaza, fiindca pe noi nu ne incanta deloc sa avem un cititor de ecran care raspunde cu intarzieri la comenzi, fie ele chiar si foarte mici.
In plus, in domeniul accesibilitatii nimic nu este stabil fiindca accesibilitatea este dependenta de cat de multe noi clase grafice se creaza si se modifica, iar in ultimii ani am avut parte de multe noutati in domeniu.
Adica daca DOM-ul se tot imbunatateste cu noile elemente html aparute in HTML5, cu atributele ARIA, si ele sunt in plina evolutie, nu cred ca este prea productiv sa se creeze o interfata standard astazi si toti producatorii de cititoare de ecran sa o foloseasca, fiindca acea interfata nu va mai oferi toate facilitatile oferite de imbunatatirile standardului html, ARIA etc.
Problema este insa ca dupa cate am inteles DOM-ul nu ofera chiar toate facilitatile necesare.
In plus, pe langa mai buna accesibilitate pe care o ofera, cititoarele de ecran si diminueaza intr-un fel accesibilitatea. Ma gandesc doar ca in timp ce unii vazatori pot accesa anumite pagini web, pentru utilizatorii de Jaws este absolut imposibil fiindca computerul aproape ca se blocheaza pe acele pagini daca ele contin foarte mult cod Javascript si html, si nu are importanta ca daca am fi putut accesa acele pagini continutul lor ar fi fost accesibil fara probleme.
Asta e din cauza ca Jaws consuma multe resurse si/sau din cauza ca creaza acel buffer virtual care pe de alta parte ne ajuta.
Este ceva asemanator cu problema accesarii unui atribut al unui obiect in mod direct sau prin intermediul unei metode care asigura o interfata standard, si care eventual asigura ca acel atribut nu este modificat etc.
In esenta idea accesarii printr-o interfata standard este buna, fiindca chiar daca clasa este modificata iar acel atribut isi schimba denumirea, el va putea fi accesat in continuare prin aceeasi metoda standard, asa ca stabilitatea este asigurata.
Pe de alta parte accesarea directa a atributului poate fi mai rapida si uneori asta conteaza.
In domeniul accesibilitatii viteza chiar conteaza, fiindca pe noi nu ne incanta deloc sa avem un cititor de ecran care raspunde cu intarzieri la comenzi, fie ele chiar si foarte mici.
In plus, in domeniul accesibilitatii nimic nu este stabil fiindca accesibilitatea este dependenta de cat de multe noi clase grafice se creaza si se modifica, iar in ultimii ani am avut parte de multe noutati in domeniu.
Adica daca DOM-ul se tot imbunatateste cu noile elemente html aparute in HTML5, cu atributele ARIA, si ele sunt in plina evolutie, nu cred ca este prea productiv sa se creeze o interfata standard astazi si toti producatorii de cititoare de ecran sa o foloseasca, fiindca acea interfata nu va mai oferi toate facilitatile oferite de imbunatatirile standardului html, ARIA etc.
Problema este insa ca dupa cate am inteles DOM-ul nu ofera chiar toate facilitatile necesare.
In plus, pe langa mai buna accesibilitate pe care o ofera, cititoarele de ecran si diminueaza intr-un fel accesibilitatea. Ma gandesc doar ca in timp ce unii vazatori pot accesa anumite pagini web, pentru utilizatorii de Jaws este absolut imposibil fiindca computerul aproape ca se blocheaza pe acele pagini daca ele contin foarte mult cod Javascript si html, si nu are importanta ca daca am fi putut accesa acele pagini continutul lor ar fi fost accesibil fara probleme.
Asta e din cauza ca Jaws consuma multe resurse si/sau din cauza ca creaza acel buffer virtual care pe de alta parte ne ajuta.
-
Stefan_Ilioaica
- Capitan
- Mesaje: 503
- Membru din: 12 Sep 2009, 21:00
- Localitate: Bucuresti
Stiu ca intrebarea poate parea prosteasca pentru cineva ce foloseste jaws de mai bine de 6 ani, dar totusi, de cand folosesc screen reader-ul n-am inteles care este treaba cu virtual-ul, cand ne afiseaza ferestrele in modul virtual.
Cum sa spun... Il stiu, doar il folosesc in viata de zi cu zi cu internet explorer si altele, da' nu prea m-am prins exact ce face, care e rolul lui.
Cum sa spun... Il stiu, doar il folosesc in viata de zi cu zi cu internet explorer si altele, da' nu prea m-am prins exact ce face, care e rolul lui.
Stefan
Jaws foloseste mai multe cursoare, unele dintre ele fiind reale, iar altele oarecum virtuale, fiindca de fapt nu exista in realitate, adica vazatorii nu le vad, nu le pot utiliza.
Aceste cursoare sunt:
- PC Cursor
- Jaws cursor
- Invisible cursor
- Virtual Cursor
PC Cursor si Jaws cursor sunt cursoare reale, care se vad pe ecran si care pot fi manevrate si de vazatori fara ajutorul Jaws.
PC Cursor este cursorul obisnuit cu care se scrie text si care apare pe ecran sub forma unei bare verticale care clipeste (adica apare si dispare rapid pentru a putea fi observat mai usor), sau poate aparea in unele programe ca o liniuta care subliniaza caracterul curent, sau ca un dreptunghi care include caracterul curent care apare cu o alta culoare etc.
Tot PC Cursor este si cursorul care apare cand selectam cu tab un buton, un element dintr-un tree view sau dintr-o lista (chiar si dintr-o lista care apare intr-o pagina web), sau cand selectam un element dintr-un meniu etc.
Cand se selecteaza un buton cursorul poate aparea sub diverse forme, depinzand de interfata grafica folosita, de versiunea sistemului de operare etc, dar in principiu este un dreptunghi punctat care se suprapune peste buton pentru a sti care este butonul curent.
In meniuri cand cursorul selecteaza un anumit element, acel element apare cu o culoare diferita pe un fond diferit de al celorlalte elemente din meniu si la fel apare si atunci cand se selecteaza un element dintr-o lista. Asta in general, fiindca pot exista si interfete in care elementul din lista sa fie incadrat cu un dreptunghi punctat...
Cursorul Jaws nu este altceva decat cursorul mouse-ului, adica acea sageata care arata locul activat in cazul in care se va apasa unul dintre butoanele mouse-ului.
Daca miscam cursorul Jaws, acea sageata se va misca pe ecran la fel cum o putem misca si fara Jaws cu mouse-ul.
Cursorul invizibil este si el un cursor virtual, care nu exista in realitate, ci care activeaza ca si cum Jaws ar mai avea un Jaws cursor care nu apare pe ecran, dar pe care il putem misca pe ecran pentru a putea citi textul care apare in diverse locuri.
(Acest cursor este util atunci cand nu putem misca cursorul Jaws, fiindca cursorul mouse-ului trebuie sa ramana intr-un anumit loc, fiindca daca l-am misca, atunci ar putea aparea altceva pe ecran).
In anumite interfete, cum este de exemplu cea oferita de Acrobat Reader, sau de browserele web, nu exista un cursor pe care vazatorii sa il poata folosi pentru a il muta de la un caracter la altul in text pentru a putea citi cu el textul. Asta fiindca intr-o pagina web nu se poate scrie, ci doar citi, iar pentru citit vazatorii au ochi.
Intr-o pagina web se poate scrie text in formulare, dar in formulare dupa ce este activat modul formular (forms mode on) se foloseste cursorul PC care apare la fel ca in orice alte formulare obisnuite.
In paginile web vazatorii au insa un cursor pe care il pot folosi pentru a selecta cu tasta tab si shift+tab diversele elemente care pot detine focusul, iar aceste elemente in mod implicit sunt linkurile si elementele care apar de obicei in formulare, ca butoane, liste, check box-uri etc.
Acel cursor marcheaza elementele selectate aproximativ ca intr-un formular standard, adica cu cate un dreptunghi punctat peste elementul curent selectat. Acest mod de selectare vizuala este in mod implicit dezactivat.
Acest cursor care este accesibil si vazatorilor si pe care si vazatorii il pot folosi pentru a accesa un browser doar cu ajutorul tastaturii nu este suficient pentru orbi, fiindca noi nu trebuie doar sa selectam elementele care pot detine focusul, ci trebuie sa mai putem face si altele, ca de exemplu:
- Sa mutam focusul la urmatoarea imagine, sau la urmatoarea lista, la urmatorul tabel, la urmatorul heading, la urmatorul frame...
- Sa citim cu el urmatorul caracter, sau urmatorul cuvant, urmatoarea linie etc.
Pentru a putea face toate acestea, Jaws creaza inca o data in memorie structura paginii curente intr-un buffer virtual, cu toate elementele ei, si ne ofera un cursor virtual cu care sa putem naviga in acea pagina virtuala.
Daca de exemplu pe o pagina exista mai multe elemente iar la un moment dat unul dintre ele este selectat, iar noi apasam tasta T, Jaws stie ca trebuie sa mute cursorul virtual pentru a selecta urmatorul tabel, iar daca apoi apasam tasta > stie sa mute cursorul la sfarsitul tabelului, iar daca apoi apasam tasta tab, stie sa mute cursorul la urmatorul element care poate obtine focusul, sau daca suntem intr-un text si apasam tastele sageti stie sa mute focusul la urmatoarea linie sau urmatorul caracter etc.
Si bineinteles, Jaws ne si citeste diverse informatii utile care nu apar pe ecran, si anume ca tabelul are nu stiu cate randuri si coloane, ca lista are nu stiu cate elemente, ca linkul curent a fost vizitat sau nu etc.
Ei bine, pe ecran nu se intampla nimic daca noi folosim Jaws pentru a muta cursorul de la o lista la un tabel de exemplu (cand ambele apar pe ecran), fiindca pentru asta folosim acel cursor virtual care este folosit doar de Jaws pentru a naviga in bufferul sau virtual.
Problema acelui cursor virtual este ca este folosit doar de Jaws, dar nu mai este trimis mai departe si catre pagina web.
Jaws ne ofera anumite taste speciale cu care putem utiliza acel cursor virtual, printre care de exemplu si tasta "L" cu care putem sari la urmatoarea lista, dar daca si pagina web foloseste un cod Javascript care accepta si el anumite taste speciale, cum ar fi pe site-ul YouTube care accepta tasta "L" pentru a derula clipul curent, atunci tasta "L" va fi interpretata de Jaws si nu va fi trimisa catre pagina web, asa ca noi vom primi eventual mesajul ca nu exista liste pe pagina in loc sa se deruleze clipul.
Cu combinatia Insert+Z se poate dezactiva cursorul virtual, si atunci putem utiliza direct pagina web fara el.
In acel caz vom vedea ca in aproape toate paginile va fi extrem de dificil de navigat, dar vom putea da comenzi directe acelor pagini, daca ele folosesc asa ceva.
In anumite pagini este mai usor de lucrat fara cursorul virtual, cum este cazul paginilor Google Spreadsheet, dar nu prea exista multe astfel de pagini.
Tot un cursor virtual este folosit si pentru a naviga in acea interfata "Ribbon" pe care cei de la Microsoft au introdus-o in ultimele versiuni de Office, fiindca ar fi fost destul de dificil de folosit un cursor obisnuit in acea structura vizuala.
Aceste cursoare sunt:
- PC Cursor
- Jaws cursor
- Invisible cursor
- Virtual Cursor
PC Cursor si Jaws cursor sunt cursoare reale, care se vad pe ecran si care pot fi manevrate si de vazatori fara ajutorul Jaws.
PC Cursor este cursorul obisnuit cu care se scrie text si care apare pe ecran sub forma unei bare verticale care clipeste (adica apare si dispare rapid pentru a putea fi observat mai usor), sau poate aparea in unele programe ca o liniuta care subliniaza caracterul curent, sau ca un dreptunghi care include caracterul curent care apare cu o alta culoare etc.
Tot PC Cursor este si cursorul care apare cand selectam cu tab un buton, un element dintr-un tree view sau dintr-o lista (chiar si dintr-o lista care apare intr-o pagina web), sau cand selectam un element dintr-un meniu etc.
Cand se selecteaza un buton cursorul poate aparea sub diverse forme, depinzand de interfata grafica folosita, de versiunea sistemului de operare etc, dar in principiu este un dreptunghi punctat care se suprapune peste buton pentru a sti care este butonul curent.
In meniuri cand cursorul selecteaza un anumit element, acel element apare cu o culoare diferita pe un fond diferit de al celorlalte elemente din meniu si la fel apare si atunci cand se selecteaza un element dintr-o lista. Asta in general, fiindca pot exista si interfete in care elementul din lista sa fie incadrat cu un dreptunghi punctat...
Cursorul Jaws nu este altceva decat cursorul mouse-ului, adica acea sageata care arata locul activat in cazul in care se va apasa unul dintre butoanele mouse-ului.
Daca miscam cursorul Jaws, acea sageata se va misca pe ecran la fel cum o putem misca si fara Jaws cu mouse-ul.
Cursorul invizibil este si el un cursor virtual, care nu exista in realitate, ci care activeaza ca si cum Jaws ar mai avea un Jaws cursor care nu apare pe ecran, dar pe care il putem misca pe ecran pentru a putea citi textul care apare in diverse locuri.
(Acest cursor este util atunci cand nu putem misca cursorul Jaws, fiindca cursorul mouse-ului trebuie sa ramana intr-un anumit loc, fiindca daca l-am misca, atunci ar putea aparea altceva pe ecran).
In anumite interfete, cum este de exemplu cea oferita de Acrobat Reader, sau de browserele web, nu exista un cursor pe care vazatorii sa il poata folosi pentru a il muta de la un caracter la altul in text pentru a putea citi cu el textul. Asta fiindca intr-o pagina web nu se poate scrie, ci doar citi, iar pentru citit vazatorii au ochi.
Intr-o pagina web se poate scrie text in formulare, dar in formulare dupa ce este activat modul formular (forms mode on) se foloseste cursorul PC care apare la fel ca in orice alte formulare obisnuite.
In paginile web vazatorii au insa un cursor pe care il pot folosi pentru a selecta cu tasta tab si shift+tab diversele elemente care pot detine focusul, iar aceste elemente in mod implicit sunt linkurile si elementele care apar de obicei in formulare, ca butoane, liste, check box-uri etc.
Acel cursor marcheaza elementele selectate aproximativ ca intr-un formular standard, adica cu cate un dreptunghi punctat peste elementul curent selectat. Acest mod de selectare vizuala este in mod implicit dezactivat.
Acest cursor care este accesibil si vazatorilor si pe care si vazatorii il pot folosi pentru a accesa un browser doar cu ajutorul tastaturii nu este suficient pentru orbi, fiindca noi nu trebuie doar sa selectam elementele care pot detine focusul, ci trebuie sa mai putem face si altele, ca de exemplu:
- Sa mutam focusul la urmatoarea imagine, sau la urmatoarea lista, la urmatorul tabel, la urmatorul heading, la urmatorul frame...
- Sa citim cu el urmatorul caracter, sau urmatorul cuvant, urmatoarea linie etc.
Pentru a putea face toate acestea, Jaws creaza inca o data in memorie structura paginii curente intr-un buffer virtual, cu toate elementele ei, si ne ofera un cursor virtual cu care sa putem naviga in acea pagina virtuala.
Daca de exemplu pe o pagina exista mai multe elemente iar la un moment dat unul dintre ele este selectat, iar noi apasam tasta T, Jaws stie ca trebuie sa mute cursorul virtual pentru a selecta urmatorul tabel, iar daca apoi apasam tasta > stie sa mute cursorul la sfarsitul tabelului, iar daca apoi apasam tasta tab, stie sa mute cursorul la urmatorul element care poate obtine focusul, sau daca suntem intr-un text si apasam tastele sageti stie sa mute focusul la urmatoarea linie sau urmatorul caracter etc.
Si bineinteles, Jaws ne si citeste diverse informatii utile care nu apar pe ecran, si anume ca tabelul are nu stiu cate randuri si coloane, ca lista are nu stiu cate elemente, ca linkul curent a fost vizitat sau nu etc.
Ei bine, pe ecran nu se intampla nimic daca noi folosim Jaws pentru a muta cursorul de la o lista la un tabel de exemplu (cand ambele apar pe ecran), fiindca pentru asta folosim acel cursor virtual care este folosit doar de Jaws pentru a naviga in bufferul sau virtual.
Problema acelui cursor virtual este ca este folosit doar de Jaws, dar nu mai este trimis mai departe si catre pagina web.
Jaws ne ofera anumite taste speciale cu care putem utiliza acel cursor virtual, printre care de exemplu si tasta "L" cu care putem sari la urmatoarea lista, dar daca si pagina web foloseste un cod Javascript care accepta si el anumite taste speciale, cum ar fi pe site-ul YouTube care accepta tasta "L" pentru a derula clipul curent, atunci tasta "L" va fi interpretata de Jaws si nu va fi trimisa catre pagina web, asa ca noi vom primi eventual mesajul ca nu exista liste pe pagina in loc sa se deruleze clipul.
Cu combinatia Insert+Z se poate dezactiva cursorul virtual, si atunci putem utiliza direct pagina web fara el.
In acel caz vom vedea ca in aproape toate paginile va fi extrem de dificil de navigat, dar vom putea da comenzi directe acelor pagini, daca ele folosesc asa ceva.
In anumite pagini este mai usor de lucrat fara cursorul virtual, cum este cazul paginilor Google Spreadsheet, dar nu prea exista multe astfel de pagini.
Tot un cursor virtual este folosit si pentru a naviga in acea interfata "Ribbon" pe care cei de la Microsoft au introdus-o in ultimele versiuni de Office, fiindca ar fi fost destul de dificil de folosit un cursor obisnuit in acea structura vizuala.
-
Manu
- General de divizie
- Mesaje: 4120
- Membru din: 02 Feb 2007, 01:15
- Localitate: Cluj-Napoca
- Contact:
Astfel de expuneri sunt foarte utile, multi isi imagineaza tot felul de lucruri false in legatura cu toate aceste cursoare utilizate de JAWS.
Sa nu uitam ca de la urmatorul JAWS va mai fi si Touch Cursor.
Sa nu uitam ca de la urmatorul JAWS va mai fi si Touch Cursor.
Errare humanum est, sed perseverare diabolicum...
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
In forum linguae Latinae venite! (via est: www.limbalatina.ro)
Pentru pagini pline de javascript (Facebook, blogger, webmaster tools, adsense, adword etc) Mozilla Firefox este cea mai buna solutie. Nu prea exista task pe care sa nu poti sa il indeplinesti cu firefox si Web Visum, singurele probleme pe care le-am intampinat au fost la labelarea butoanelor pe aici pe acolo, dar in rest merge brici
Blogul lui Sorin
Magazin online cu produse pentru nevăzători şi slab văzători
Victoria nu este cel mai important lucru, ci este singurul lucru important!
Magazin online cu produse pentru nevăzători şi slab văzători
Victoria nu este cel mai important lucru, ci este singurul lucru important!
Depinde de ce site trebuie sa folosesti. In unele Chrome functioneaza mai bine, in altele Chrome functioneaza iar Internet Explorer si Firefox blocheaza computerul deci nu se pot utiliza deloc. Asta desi Chrome este cel mai putin accesibil dintre cele 3 browsere principale pentru Windows.
Unele site-uri, ca Pivotal Tracker de exemplu, versiunea beta, nici nu permit utilizarea Internet Explorer sub Windows XP fiindca e prea vechi. Si nici site-ul Basecamp nu permite. Iar alte site-uri permit dar functioneaza destul de rau fiindca nu sunt facute pentru a tine seama de "backward compatibility". De fapt, azi cand totul se misca atat de rapid, multi nu mai tin cont de nicio compatibilitate, iar asta este spre dezavantajul orbilor a caror tehnologii sunt intotdeauna in urma.
Uneori trebuie sa poti folosi cursorul JAWS, dar cu Firefox nu se poate. Am adaugat eu acel mesaj de la FreedomScientific in care am aratat cum se poate seta Firefox ca sa se poata folosi cursorul Jaws in el, dar nu functioneaza in toate site-urile. De exemplu in Pivotal Tracker versiunea beta nu se poate fiindca citeste tot felul de caractere ciudate, parca ar fi caractere aleatoare.
Iar apoi Firefox mai are o problema in comparatie cu IE8. Este mai lent. Si in plus mai si crapa uneori.
Asa ca bine ca exista mai multe, ca toate la un loc fac cat un browser bun.
Unele site-uri, ca Pivotal Tracker de exemplu, versiunea beta, nici nu permit utilizarea Internet Explorer sub Windows XP fiindca e prea vechi. Si nici site-ul Basecamp nu permite. Iar alte site-uri permit dar functioneaza destul de rau fiindca nu sunt facute pentru a tine seama de "backward compatibility". De fapt, azi cand totul se misca atat de rapid, multi nu mai tin cont de nicio compatibilitate, iar asta este spre dezavantajul orbilor a caror tehnologii sunt intotdeauna in urma.
Uneori trebuie sa poti folosi cursorul JAWS, dar cu Firefox nu se poate. Am adaugat eu acel mesaj de la FreedomScientific in care am aratat cum se poate seta Firefox ca sa se poata folosi cursorul Jaws in el, dar nu functioneaza in toate site-urile. De exemplu in Pivotal Tracker versiunea beta nu se poate fiindca citeste tot felul de caractere ciudate, parca ar fi caractere aleatoare.
Iar apoi Firefox mai are o problema in comparatie cu IE8. Este mai lent. Si in plus mai si crapa uneori.
Asa ca bine ca exista mai multe, ca toate la un loc fac cat un browser bun.
Ah, habar nu am, nu am mai folosit IE 8 de doi ani, sau poate mai bine. Eu folosesc IE 11 din cand in cand si Firefox 28
Blogul lui Sorin
Magazin online cu produse pentru nevăzători şi slab văzători
Victoria nu este cel mai important lucru, ci este singurul lucru important!
Magazin online cu produse pentru nevăzători şi slab văzători
Victoria nu este cel mai important lucru, ci este singurul lucru important!
Si eu folosesc tot Firefox 28, dar totusi are acele probleme de accesibilitate despre care am amintit.
Am testat si IE11 sub Windows 7, insa functiona destul de rau, asa ca am trecut la IE10 care nu functioneaza nici el extraordinar, dar tot mai bine decat IE11.
Inca suspectez ca placa video sau driverul ei este implicata in problemele pe care le are IE11, dar totusi ea functioneaza foarte bine sub Windows XP...
Am testat si IE11 sub Windows 7, insa functiona destul de rau, asa ca am trecut la IE10 care nu functioneaza nici el extraordinar, dar tot mai bine decat IE11.
Inca suspectez ca placa video sau driverul ei este implicata in problemele pe care le are IE11, dar totusi ea functioneaza foarte bine sub Windows XP...