El CSS i el JavaScript, quan s’utilitzen correctament, també tenen el potencial de permetre experiències web accessibles ... o poden perjudicar significativament l’accessibilitat si s’utilitzen malament. Aquest article descriu algunes de les pràctiques recomanades amb CSS i JavaScript que s’han de tenir en compte per garantir que fins i tot el contingut complex sigui el més accessible possible.
| Requisits previs: | Alfabetització bàsica en informàtica, comprensió bàsica d’HTML, CSS i JavaScript, i comprensió de què és l’accessibilitat. |
|---|---|
| Objectiu: | Familiaritzar-vos amb l’ús adequat de CSS i JavaScript als vostres documents web per maximitzar l’accessibilitat i no restar-li importància. |
CSS i JavaScript no tenen la mateixa importància immediata per a l’accessibilitat que l’HTML, però tot i això poden ajudar o perjudicar l’accessibilitat, segons com s’utilitzin. Dit d'una altra manera, és important que tingueu en compte alguns consells sobre bones pràctiques per assegurar-vos que l'ús de CSS i JavaScript no arruïni l'accessibilitat dels vostres documents.
Comencem considerant CSS.
És possible utilitzar CSS per fer que qualsevol element HTML sembli qualsevol cosa, però això no vol dir que ho hàgiu de fer. Tal com hem esmentat amb freqüència en el nostre article HTML: Una bona base per a l'accessibilitat, heu d’utilitzar l’element semàntic adequat per a cada funcionalitat, sempre que sigui possible. Si no ho feu, pot causar problemes de confusió i usabilitat per a tothom, però sobretot per als usuaris amb discapacitat. L’ús de semàntica correcta té molt a veure amb les expectatives dels usuaris: els elements tenen un aspecte i un comportament determinats segons la seva funcionalitat, i els usuaris esperen aquestes convencions habituals.
Per exemple, un usuari de lector de pantalla no pot navegar per una pàgina a través dels seus elements d’encapçalament si el desenvolupador no ha utilitzat adequadament elements d’encapçalament per marcar el contingut. De la mateixa manera, un encapçalament perd el seu propòsit visual si hi apliqueu estil perquè no sembli un encapçalament.
Encapçalaments, paràgrafs, llistes — el contingut bàsic del text de la vostra pàgina:
<h1>Encapçalament</h1> <p>Paràgraf</p> <ul> <li>La meva llista</li> <li>té dos ítems.</li> </ul>
Un CSS típics pot tenir aquest aspecte:
h1 {
font-size: 5rem;
}
p, li {
line-height: 1.5;
font-size: 1.6rem;
}
Hauríeu de:
Consulteu Fonaments de text HTML i Estilitzar text per obtenir més informació.
Marcatge en línia que confereix un èmfasi específic al text que embolcalla:
<p>L'aigua està <em>molt calenta</em>.</p>
<p>Les gotes d’aigua que es recullen a les superfícies s’anomenen <strong>condensació</strong>.</p>
Potser voldreu afegir un color simple al text emfatitzat:
strong, em {
color: #a60000;
}
Tot i això, poques vegades haureu d'aplicar estil als elements d’èmfasi de manera significativa. Les convencions estàndard del text en negreta i cursiva són molt reconeixibles i canviar l’estil pot provocar confusió. Per obtenir més informació sobre l’èmfasi, vegeu Èmfasi i importància.
Un element que permet associar una abreviatura, acrònim o inicialització a la seva expansió:
<p>El contingut web es marca fent servir <abbr title="Hypertext Markup Language">HTML</abbr>.</p>
De nou, és possible que vulgueu donar-li estil de manera senzilla:
abbr {
color: #a60000;
}
La convenció d’estil reconeguda per a les abreviatures és un subratllat puntejat i no és prudent desviar-se’n significativament. Per obtenir més informació sobre les abreviatures, vegeu Abreviatures.
Hiperenllaços — la manera d’arribar a nous llocs del web:
<p>Visiteu la <a href="https://www.mozilla.org">pàgina d'inici de Mozilla</a>.</p>
A continuació es mostra un estil d’enllaços molt senzill:
a {
color: #ff0000;
}
a:hover, a:visited, a:focus {
color: #a60000;
text-decoration: none;
}
a:active {
color: #000000;
background-color: #a60000;
}
Les convencions d’enllaç estàndard són el subratllat i un color diferent (per defecte, el blau) en el seu estat estàndard, una altra variació de color quan l’enllaç s’ha visitat prèviament (per defecte: porpra) i un altre color quan l’enllaç està activat (per defecte: vermell). A més, el cursor canvia a una icona de punter quan es passa per sobre dels enllaços i l’enllaç rep un ressaltat quan està enfocat (per exemple, mitjançant la tecla de tabulació) o activat. La imatge següent mostra el destacat tant a Firefox (rodejat de punts) com a Chrome (rodejat de blau):
Podeu ser creatius amb els estils d’enllaços, sempre que continueu donant informació als usuaris quan interactuen amb els enllaços. Definitivament, alguna cosa hauria de passar quan els estats canvien i no heu d’eliminar el cursor del punter ni el destacat (outline): tots dos són ajudes d’accessibilitat molt importants per a aquells que fan servir controls de teclat.
Elements que permeten als usuaris introduir dades als llocs web:
<div> <label for="name">Entra el teu nom</label> <input type="text" id="name" name="name"> </div>
Podeu veure un bon exemple de CSS al nostre exemple form-css.html (vegeu-lo també en viu).
La majoria de CSS que escriureu per als formularis serà per donar dimensions als elements, alinear etiquetes i entrades i aconseguir que es vegin ordenats i polits.
Tanmateix, no us heu de desviar massa de la retroalimentació visual esperada que reben els elements de formulari quan prenen el focus, que és bàsicament la mateixa que als enllaços (vegeu més amunt). Podeu definir els estats de focus i hover del formulari per fer que aquest comportament sigui més coherent entre navegadors o que s’adapti millor al disseny de la vostra pàgina, però no us en desfeu del tot: de nou, la gent confia en aquestes pistes per ajudar-los a saber què passa.
Taules per presentar dades tabulars.
Podeu veure un bon exemple d'HTML i CSS de taula al nostre exemple table-css.html (vegeu-lo també en viu).
Generalment, el CSS de les taules serveix perquè la taula s’adapti millor al vostre disseny i sigui menys lletja. És una bona idea assegurar-se que les capçaleres de les taules destaquen (normalment amb negreta) i fer servir les tires de zebra per fer més fàcil analitzar les diferents files.
Quan trieu un esquema de colors per al vostre lloc web, assegureu-vos que el color del text (primer pla) contrasta bé amb el color de fons. El vostre disseny pot semblar genial, però no és bo si les persones amb deficiències visuals com el daltonisme no poden llegir el vostre contingut.
Hi ha una manera fàcil de comprovar si el vostre contrast és prou gran per no causar problemes. Hi ha una sèrie d’eines de comprovació de contrast en línia on podeu introduir els colors de primer pla i de fons per comprovar-los. Per exemple, el Color Contrast Checker de WebAIM és senzill d'utilitzar i proporciona una explicació del que necessiteu per adaptar-vos als criteris WCAG sobre contrast de color.
Nota: una relació de contrast elevada també permetrà que tothom que faci servir un telèfon intel·ligent o una tauleta amb pantalla brillant pugui llegir millor les pàgines quan es troba en un entorn brillant, com ara al sol.
Un altre consell és no confiar només en el color per a les indicacions/informació, ja que no servirà per a aquells que no poden veure el color. En lloc de marcar els camps de formulari obligatoris en vermell, per exemple, marqueu-los amb un asterisc i en vermell.
Hi ha molts casos en què un disseny visual requereix que no es mostri tot el contingut alhora. Per exemple, a l’exemple del quadre d’informació amb pestanyes (vegeu el codi font), tenim tres panells d’informació, però els posicionem els uns sobre els altres i proporcionem pestanyes on es pot fer clic per mostrar-les (també és accessible per al teclat: podeu utilitzar alternativament el tabulador i Return/Enter per a seleccionar-les).
Als usuaris del lector de pantalla no els importa res d’això: estan satisfets amb el contingut sempre que tingui sentit l’ordre al codi font i puguin arribar a tot. El posicionament absolut (tal com s’utilitza en aquest exemple) es considera generalment com un dels millors mecanismes per amagar el contingut per obtenir efectes visuals, perquè no impedeix que els lectors de pantalla hi accedeixin.
D'altra banda, no heu d'utilitzar {{cssxref ("visibility")}}:hidden o {{cssxref ("display")}}: none, perquè oculten el contingut als lectors de pantalla. Tret que, per descomptat, hi hagi una bona raó per la qual vulgueu que aquest contingut quedi amagat als lectors de pantalla.
Nota: Invisible Content Just for Screen Reader Users té molts més detalls útils sobre aquest tema.
Els usuaris poden sobreescriure els vostres estils amb els seus propis estils personalitzats, per exemple:
Els usuaris poden fer-ho per diversos motius. Un usuari amb discapacitat visual pot voler fer més gran el text a tots els llocs web que visita o un usuari amb deficiència de color severa pot voler posar tots els llocs web en colors d’alt contrast que siguin fàcils de veure. Qualsevol que sigui la necessitat, hauríeu de sentir-vos còmodes amb això i fer que els vostres dissenys siguin prou flexibles perquè aquests canvis funcionin al vostre disseny. Per exemple, és possible que vulgueu assegurar-vos que la vostra àrea de contingut principal pot admetre text més gran (potser començarà a desplaçar-se per permetre que es vegi tot), i no només l’amagarà, ni es trencarà completament.
El JavaScript també pot trencar l'accessibilitat, segons com s'utilitzi.
El JavaScript modern és un llenguatge potent i podem fer-hi moltes coses, avui dia, des de contingut senzill i actualitzacions d’interfície d’usuari fins a jocs 2D i 3D completament desenvolupats. No hi ha cap regla que digui que tot el contingut ha de ser accessible al 100% per a totes les persones; però cal que feu tot el que pugueu i que les vostres aplicacions siguin tan accessibles com sigui possible.
El contingut i la funcionalitat senzills són fàcils de fer accessibles — per exemple, text, imatges, taules, formularis i botons que activen les funcions. Tal com hem vist al nostre article HTML: Una bona base per l'accessibilitat, les consideracions clau són:
També vam veure un exemple de com utilitzar JavaScript per generar funcionalitats que hi falten - vegeu Tornar a afegir l'accessibilitat de teclat. Això no és l'ideal; de fet, només hauríeu d'utilitzar l'element adequat per a cada feina, però demostra que és possible en situacions en què per alguna raó no es pot controlar el marcatge que s'utilitza. Una altra manera de millorar l’accessibilitat dels ginys JavaScript no semàntics és utilitzar WAI-ARIA per proporcionar semàntica addicional als usuaris de lectors de pantalla. El següent article també tractarà això en detall.
Les funcionalitats complexes, com ara els jocs en 3D, no són tan fàcils de fer accessibles: un joc en 3D complex creat amb WebGL es mostrarà en un element {{htmlelement ("canvas")}}), que actualment no té cap capacitat per proporcionar alternatives textuals o altres informacions per a usuaris amb discapacitats visuals greus. És discutible que un joc d’aquest tipus tingui realment aquest grup de persones com a part del seu públic objectiu principal, i no seria raonable esperar que es fes 100% accessible per a persones invidents, tot i que es podrien implementar controls de teclat perquè el puguin utilitzar usuaris que no fan servir el ratolí, i fer que l’esquema de colors sigui prou contrastat per ser utilitzat per persones amb deficiències de color.
El problema sol venir quan la gent confia massa en JavaScript. De vegades veureu un lloc web on tot s’ha fet amb JavaScript: l’HTML l’ha generat JavaScript, el CSS l’ha generat JavaScript, etc. Això comporta tota mena de problemes d’accessibilitat i altres d'associats, de manera que no és aconsellable.
A més d'utilitzar l'element adequat per a cada feina, també us heu d'assegurar que utilitzeu la tecnologia adequada per a cada cosa. Penseu bé si necessiteu aquest brillant quadre d’informació 3D basat en JavaScript o si amb un simple text ja faríeu. Penseu bé si necessiteu un complex giny de formulari no estàndard o si una entrada de text serviria. I no genereu tot el vostre contingut HTML mitjançant JavaScript, si és possible.
Hauríeu de fer servir JavaScript no obstructiu quan creeu el vostre contingut. La idea del JavaScript no obstructiu és que s’ha d’utilitzar sempre que sigui possible per millorar funcionalitats i no per construir-la del tot: les funcions bàsiques haurien de funcionar idealment sense JavaScript, tot i que ja sabem que això no sempre és una opció. Un altre cop, una gran part és fer servir la funcionalitat integrada del navegador sempre que sigui possible.
Un bon exemple d'usos de JavaScript no obstructiu inclou:
<video>s HTML5 que siguin accessibles per als usuaris de teclat, juntament amb un enllaç directe al vídeo que es pot utilitzar per accedir-hi si JavaScript no està disponible (els controls predeterminats del navegador per a <video> no són accessibles per teclat a la majoria de navegadors).Com a exemple, hem escrit un exemple de validació de formulari al client "ràpid i brut": vegeu form-validation.html (vegeu també la demostració en viu). Aquí veureu un formulari senzill: quan intenteu enviar el formulari amb un o ambdós camps buits, l'enviament falla i apareix un quadre de missatge d'error per indicar-vos què no funciona.
Aquest tipus de validació de formularis és no obstructiu: podeu utilitzar el formulari perfectament sense que estigui disponible JavaScript, i qualsevol implementació de formulari assenyada també tindrà activa la validació del servidor, perquè és massa fàcil per als usuaris malintencionats saltar-se la validació al client (per exemple, desactivant JavaScript al navegador). Però la validació al client és molt útil per informar d'errors: els usuaris poden veure els errors que cometen a l'instant, en lloc d'haver d'esperar un viatge d'anada i tornada al servidor i una recàrrega de la pàgina. Aquest és un avantatge clar d’usabilitat.
Nota: La validació al servidor no s'ha implementat en aquesta senzilla demostració.
També hem fet que la validació d’aquest formulari sigui força accessible. Hem utilitzat elements {{htmlelement ("label")}}}) per assegurar-nos que les etiquetes del formulari estiguin lligades sense ambigüitats a les seves entrades, de manera que els lectors de pantalla les puguin llegir conjuntament:
<label for="name">Entra el teu nom:</label> <input type="text" name="name" id="name">
La validació només la fem quan s’envia el formulari, de manera que no actualitzem la interfície d’usuari massa sovint, cosa que pot confondre als usuaris de lectors de pantalla (i possiblement d’altres):
form.onsubmit = validate;
function validate(e) {
errorList.innerHTML = '';
for(let i = 0; i < formItems.length; i++) {
const testItem = formItems[i];
if(testItem.input.value === '') {
errorField.style.left = '360px';
createLink(testItem);
}
}
if(errorList.innerHTML !== '') {
e.preventDefault();
}
}
Nota: En aquest exemple, amaguem i mostrem el quadre de missatge d'error mitjançant posicionament absolut en lloc d'un altre mètode, com ara visibility o display, perquè no interfereix amb el fet que el lector de pantalla pugui llegir-ne contingut.
La validació real del formulari seria molt més complexa que això: voldríeu comprovar que el nom introduït sembli un nom, l’edat introduïda sigui realment un número i sigui realista (per exemple, no negativa i amb menys de 4 dígits). Aquí simplement hem implementat una comprovació senzilla: que s'ha introduït un valor a cada camp d'entrada (if(testItem.input.value === '')).
Quan s’hagi realitzat la validació, si passa la prova, s’envia el formulari. Si hi ha errors (if (errorList.innerHTML!== ")), no enviem el formulari (utilitzant preventDefault()) i mostrem els missatges d'error creats (vegeu més avall). Aquest mecanisme significa que els errors només es mostraran si hi ha errors, cosa que és millor per a la usabilitat.
Per a cada entrada que no tingui un valor completat quan s’envia el formulari, creem un element de llista amb un enllaç i l’inserim a errorList.
function createLink(testItem) {
const listItem = document.createElement('li');
const anchor = document.createElement('a');
anchor.textContent = 'El camp ' + testItem.input.name + ' és buit: entreu ' + testItem.input.name + '.';
anchor.href = '#' + testItem.input.name;
anchor.onclick = function() {
testItem.input.focus();
};
listItem.appendChild(anchor);
errorList.appendChild(listItem);
}
Cada enllaç té un doble propòsit: indica quin és l'error i, a més, permet fer-hi clic / activar-lo per saltar directament a l'element d'entrada en qüestió i corregir-lo.
Nota: la part focus() d’aquest exemple és una mica complicada. Chrome i Edge (i les versions més recents d’IE) donen focus a l’element quan es fa clic a l’enllaç, sense necessitat del bloc onclick / focus(). Safari només ressaltarà l’element del formulari amb l’enllaç, de manera que necessita el bloc onclick / focus() per donar-hi focus realment. Firefox no dona focus correctament a les entrades en aquest context, de manera que els usuaris de Firefox no poden aprofitar-ho actualment (tot i que la resta funciona bé). El problema a Firefox s'hauria de solucionar aviat — s'està treballant per proporcionar a Firefox un comportament equivalent al d'altres navegadors (vegeu {{bug(277178)}}).
A més, l’errorField es col·loca a la part superior del codi font (tot i que es posiciona de manera diferent a la interfície d'usuari mitjançant CSS), cosa que significa que els usuaris poden esbrinar exactament què passa amb els enviaments del formulari i accedir als elements d’entrada en qüestió tornant al començament de la pàgina.
Com a nota final, hem utilitzat alguns atributs WAI-ARIA a la nostra demostració per ajudar a resoldre els problemes d’accessibilitat causats per àrees de contingut que s’actualitzen constantment sense que es recarregui la pàgina (els lectors de pantalla no ho recolliran ni avisaran els usuaris per defecte):
<div class="errors" role="alert" aria-relevant="all"> <ul> </ul> </div>
Explicarem aquests atributs al nostre proper article, que cobreix WAI-ARIA amb molt més detall.
Nota: Probablement, alguns de vosaltres pensareu en el fet que els formularis HTML5 tenen mecanismes de validació integrats, com ara els atributs required, min/minlength i max/maxlength (vegeu la referència de l’element {{htmlelement("input")}}) per obtenir més informació ). No els hem utilitzat a la demostració perquè el suport de diversos navegadors per a ells és inadequat (per exemple, només existeix en IE10 i superior).
Nota: Usable and Accessible Form Validation and Error Recovery, de WebAIM, dona més informació útil sobre validació accessible de formularis.
Hi ha altres coses que cal tenir en compte a l’hora d’implementar JavaScript i pensar en l’accessibilitat. N’afegirem més a mesura que les trobem.
Com ja deveu saber, la majoria de les interaccions dels usuaris s’implementen en JavaScript del costat del client mitjançant gestors d’esdeveniments (event handlers), que ens permeten executar funcions en resposta a determinats esdeveniments que succeeixen. Alguns esdeveniments poden tenir problemes d’accessibilitat. El principal exemple que trobareu són esdeveniments específics del ratolí, com ara mouseover, mouseout, dblclick, etc. La funcionalitat que s'executa en resposta a aquests esdeveniments no serà accessible mitjançant altres mecanismes, com ara els controls del teclat.
Per mitigar aquests problemes, hauríeu de duplicar aquests esdeveniments amb esdeveniments similars que es puguin activar per altres mitjans (els anomenats controladors d’esdeveniments independents de dispositiu); focus i blur proporcionarien accessibilitat als usuaris de teclat.
Vegem un exemple que destaca quan pot ser útil fer-ho. Potser volem proporcionar una imatge en miniatura que mostri una versió més gran de la imatge quan s'hi passi per sobre amb el ratolí o s'hi doni focus (com passaria en un catàleg de productes de comerç electrònic).
Hem fet un exemple molt senzill que podeu trobar a mouse-and-keyboard-events.html (vegeu també el codi font). El codi presenta dues funcions que mostren i amaguen la imatge ampliada; són executats per les línies següents que els configuren com a gestors d'esdeveniments:
imgThumb.onmouseover = showImg; imgThumb.onmouseout = hideImg; imgThumb.onfocus = showImg; imgThumb.onblur = hideImg;
Les dues primeres línies executen les funcions quan el punter del ratolí passa per sobre i surt de sobre de la miniatura, respectivament. Tot i això, no ens permetrà accedir a la vista ampliada mitjançant el teclat; per permetre-ho, hem inclòs les dues darreres línies, que executen les funcions quan la imatge agafa i perd focus. Això es pot fer prement el tabulador fins arribar a la imatge, perquè hi hem inclòs tabindex="0".
L’esdeveniment click és interessant: sembla que depengui del ratolí, però la majoria de navegadors activaran els controladors d’esdeveniments onclick en prémer Retorn sobre un enllaç o element de formulari que tingui focus, o quan es toqui a aquest element en un dispositiu de pantalla tàctil. Això no funciona de manera determinada, però, si permeteu que un esdeveniment al qual no es pot donar focus per defecte prengui el focus mitjançant tabindex. En aquests casos, heu de detectar específicament quan es prem aquesta tecla exacta (consulteu Tornar a afegir l'accessibilitat de teclat).
Heu arribat al final d’aquest article. En recordeu la informació més important? Podeu trobar algunes proves addicionals per verificar que reteniu aquesta informació abans de continuar. Vegeu Test your skills: CSS and JavaScript accessibility.
Esperem que aquest article us hagi donat una bona quantitat de detalls i comprensió sobre els problemes d’accessibilitat relacionats amb l’ús de CSS i JavaScript a les pàgines web.
Tot seguit, WAI-ARIA!