PHP : les limites de l'accessibilité ?

Bien l'bonjour !

Tout d'abord, je ne sais pas si je poste dans le salon approprié. Il me semble que oui, mais dans le cas contraire, toutes mes excuses.

Je signalement d'autre part que ce topic n'est pas véritablement voué à obtenir une aide quelconque (bien que sur le fond, chacun pourra je pense y trouver son compte), mais plutôt à éclaircir un point que je trouve relativement sombre (sans être obscur ).

Le PHP, ou les limites de l'accessibilité ?

C'est en effet la question que je me pose...
Tenez, prenon l'exemple concret d'Alsacreations :
Le forum est sympa, accessible, tout ça...
Pour autant, y a des limites là aussi non ?
Par exemple les balises ne permettent pas de renseigner comme il faut l'attribut alt (d'un autre côté, en tout objectivité, sur un forum traitant d'autre chose que des standards est-ce que les membres s'obligeraient à la remplir, si cette fonction existait ?).
De même, comment signaler un changement de langue ?

Moi par exemple, sur le site que je développe actuellement, j'ai un script PHP (merci pompage.net et un ami) qui permet de détecter si le navigateur peut interpréter la page en XML ou pas. Si c'est le cas, le DOCTYPE est XHTML 1.1 (avec content="application/xhtml+xml;), sinon c'est du XHTML 1.0 Strict (avec content="text/html;).

Or, au niveau des langues (enfin, je parle de l'attribut lang en fait, et non de la langue principale de la page), si l'on code en XHTML 1.0 Strict, il faut lang="la_langue", et si c'est en XHTML 1.1, il faut xml:lang="la_langue"... et bien entendu selon le DOCTYPE l'un des deux n'est pas pris en charge (je dis ça car j'avais lu je ne sais plus où qu'il fallait alors faire <balise xml:lang="la_langue" lang="la_langue"></balise>).

Bon, jusque là, si l'on ne dynamise pas trop trop les pages, ça passe :
On crée un petit script qui permet de mettre l'un ou l'autre attribut selon que le navigateur gère le XML ou pas.

Mais sur un forum, si je m'amuse par exemple à mettre « Hello World », comment signaler que je ne parle pas français ? Et quand bien même ce serait possible, il faudrait en plus s'assurer que la balise change selon le DOCTYPE...

Pas facile...

Il en va de même pour les listes :
Déjà, il faut fermer le paragraphe avant la liste. Jusque là, ça va.
Mais une fois la liste terminée, il faut rouvrir un paragraphe (bon faut dire que je ne suis pas une lumière en PHP hein, alors j'ai tenté le coup, et moi ça marchait pas. Apparemment il ouvre automatiquement un paragraphe ou j'sais plus quoi, bref, ça passait pas quoi qu'il en soit).

Pareil avec les <br />, logiquement quand on va plusieurs fois à la ligne ça devrait changer le paragraphe, et pas lister la balise indéfiniment.

Bref, on pourrait continuer longtemps comme ça...

Alors j'en viens à me demander, dans le fond, si le PHP (pourtant extrêmement utile), n'est pas un frein à l'accessibilité.
Bien que cela me chagrine, il faut supposer qu'arrivé un moment, malgré tous les efforts mis en &#339;uvre, viser un site (dynamique, donc surtout forum) 100% accessible n'est pas possible, non ?


Bref, j'ai fait une recherche sur le forum, et n'ai rien trouvé à ce sujet.
Mais moi qui doit justement en monter un, de forum, je me pose la question.

J'ai vu que vous parliez des "usines à gaz" comme phpBB ou IPB, mais concernant phpBB, depuis la dernière version, ils ont fait beaucoup d'efforts quand même (page d'index en XHTML 1.0 Strict, et une seule faute. J'ai testé un topic galement : 5 fautes, ce qui comparé à avant est plutôt bon signe), mais est-ce véritablement possible d'aller plus loin avec ce genre de pages dynamiques ?
Modifié par Poulpette (11 Feb 2008 - 14:13)

Les limites que tu évoques ne sont pas liées au php, mais au script qui à été développé. Pour reprendre l'exemple, il aurait tout a fait été possible de permettre d'intégrer la gestion de l'attribut alt des images.

En vrac car je n'ai pas trop le temps, voici quelques réponses car je ne peux pas laisser passer quelques erreurs dans le message de Poulpette:
1. PHP en soi n'a rien à voir avec l'accessibilité. Un navigateur n'en a rien à battre du langage de script qui lui délivre son code HTML; ce qui lui importe, c'est le code HTML produit. Et là, PHP, ASP, JSP et autres Ruby on Rails sont à égalité, puisqu'il me semble qu'on peut leur faire produire tout et n'importe quoi.
2. La validation du code HTML n'a que peu à voir avec l'accessibilité. Je peux t'écrire des centaines de modèles de pages (bon, allez, quelques douzaines...) XHTML 1.0 strict mais totalement inacessibles (par exemple, parce que tout le code est produit par du JavaScript...). De plus, il y a des pages non valides qui sont accessibles. Un alt qui manque sur une image dans une page sur laquelle il n'y a rien d'autre à reprocher par ailleurs la rend invalide, mais cette page est quand même accessible.
3. Du coup, cela me fournit une transition toute trouvée pour le dernier point: viser un site 100% accessible est impossible. L'accessibilité, tout l'ergonomie d'ailleurs, ce n'est pas du tout ou rien. Ce sont des compromis, et il arrive par exemple que plus on fait des efforts pour améliorer l'accessibilité de la page en se focalisant sur une catégorie d'utilisateurs, plus on la rend difficile à utiliser pour une autre catégorie (exemple: vidéos sous-titrées et descriptions simultanées...) On peut faire des efforts à la hauteur de ses moyens, mais il faut tordre le coup au mythe de la page, et a fortiori du site, qui serait "100% accessible" (sauf cas extrême de la page "Bonjour tout le monde!").

Bonjour,

concernant ce forum Alsacreations.com développé par dew, il a avant tout été développé pour un FAI grand public, pas spécifiquement pour ici. Et ça a été commencé il y a fooort longtemps, bien avant que les standards soient "à la mode" ou connus en France ... Quoique le changement de langue alsacien/français pourrait être utile

Enfin, "100% accessible" n'existe pas, bis repetita. Il n'y a pas de mesure de l'accessibilité dans l'absolu comme il existe une vitesse de la lumière qu'aucun corps dans l'Univers ne peut dépasser, on peut rendre plus accessible (ou moins) une page et un site, on peut comparer par rapport à un référentiel donné mais rien n'empêche de faire mieux que respecter WCAG 1.0 ou mieux que Accessiweb niveau Or par exemple.
Mais ça n'empêche donc pas de faire toujours mieux
Modifié par Felipe (11 Feb 2008 - 14:27)

La question posée n'est pas tant celle de PHP que celle de la production multi-contributeurs de contenus accessibles. L'exemple des forums est éclairant de ce point de vue : on demande à des utilisateurs d'injecter du contenu sans les guider, les conseiller, les sensibiliser, ni même leur fournir d'outils pour cela.
Les exemples ne manquent pas :
- images envoyées sans possibilité de renseigner leur alternative textuelle si besoin est (sans parler de la longueur contrôlable de cette alternative)
- passages de textes écrits dans une langue étrangère sans possibilité de le signaler
- entrée d'acronymes sans explicitation
- etc.

Plus basiquement, la question est celle des solutions multi-contributeurs qui doivent répondre à trois besoins distincts en terme d'accessibilité :
1. produire du contenu injecté conforme aux recommandations, et si possible valide
2. présenter des interfaces utilisateurs elles-mêmes conformes et valides
3. guider le contributeur dans la production du contenu qu'il se propose d'injecter.
Tout ça fait beaucoup.

La création de pages-interfaces conformes relève de la responsabilité de l'auteur-développeur.
La mise en place d'outils d'assistance, de conseils, de contrôles pré-publication destinés aux utilisateurs-contributeurs aussi, mais c'est quasiment incontrôlable puisque ça relève de la bonne volonté de l'utilisateur final : s'il ne veut pas jouer le jeu rien ne l'y contraindra.
Quant à la production finale de contenus accessibles, elle relève à la fois de la qualité, de la pertinence et des contrôles offerts par les outils et cette même bonne volonté.

Exemple : dans ma solution CMS perso, pour tout chargement d'image il est demandé, si l'image joue un rôle assimilable à un morceau de texte (si elle peut être remplacée par...) de la décrire en moins de 60 caractères (un script contrôle la longueur de la chaine envoyée) et de laisser vide si l'image n'est que décorative ou si elle ne fait qu'illustrer un passage du texte sans rien apporter de plus. Cette façon de voir est déjà litigieuse mais pour le moment je n'en ai pas de meilleure à proposer.
Mais si l'auteur décide de mettre n'importe quoi, genre "gdf s hgfdg hscf shgd chsgdcf sdhg", ou rien alors qu'il faudrait, aucun contrôle n'est possible.

Le problème est que plus l'outil web devient interactif et ouvert aux multi-utilisateurs (ça n'a rien à voir avec Php, Ajax pose les mêmes questions, avec même une ou deux en plus...) et plus l'accessibilité des contenus est difficile à maîtriser (on parle même pas là de la garantir au minimum...). Pour ce forum, qu'il ait été développé il y a longtemps, comme Felipe le signale, ou pas, ne change pas grand'chose : même s'il y avait les outils pour, ce sont les utilisateurs qui le rendraient in fine plus ou moins accessible. Et vu le nombre de posts concernant TOUT sauf l'application des standards (et l'intérêt pour...) , on peut penser qu'il ne le serait pas plus qu'il ne l'est aujourd'hui en l'absence de ces outils.

Bonsoir,

Que de bonnes choses ont été dites

/me ne dit rien. Il devrait y avoir à lire notamment sur ce sujet, bientôt...
Modifié par Laurent Denis (11 Feb 2008 - 18:32)

Bonjour

Laurent Denis a écrit :
Il devrait y avoir à lire notamment sur ce sujet, bientôt...

Oui, mais quand ? C'est qu'on s'impatiente !!!

Arsene a écrit :
de la décrire en moins de 60 caractères

En passant : tu peux porter cette limite à 80 caractères, ou mieux ne pas imposer de limite (mais préciser que le contenu de alt doit être concis).

Cette limite ne se justifie en effet que dans le contexte spécifique d'une labellisation Accessiweb (ou anysurfer, etc), et pose quelques problèmes.

Deux règles d'or :

1. small is beautifull
2. tu donnes 60 au client, il en prend 80

Arsene a écrit :
(un script contrôle la longueur de la chaine envoyée)

Si le script se contente d'une alerte et ne bloque pas à une longueur donnée, pourquoi pas. Je vois trop souvent des alternatives dénuées de sens ou conduisant à une perte d'information parce qu'on a cru bien faire

Bonsoir bonsoir,

Je n'ai pas eu le temps de poster plus tôt, et vous présente mes excuses pour la confusion de mon post.
En effet, j'ai fait l'erreur de montrer que PHP était un frein à l'accessibilité, alors qu'en fait ce n'était pas ma pensée.
Arsene a compris ce que je voulais dire, mais j'aurais du être plus claire dès le début, encore désolée.

Je parlais donc bien de la façon dont l'accessibilité est gérée lorsque tout est « automatisé » (formulaires, et ainsi de suite) et géré par plusieurs utilisateurs.
Le PHP n'ayant à proprement parlé rien à voir avec ça.


Bref, par rapport à vos réponses (principalement celle d'Arsene), je suppose donc qu'il est impossible à un moment de tout contrôler, comme sur les fora, c'est ça ? (par exemple, le coup du lang)

Bonjour,

C'est le problème de tous les espaces publics (forums, commentaires), mais en fait plus généralement des CMS.

Il est en effet impossible de "tout contrôler", car:

- accroître le contrôle sur les contenus va à l'encontre du rôle le plus souvent dévolu aux CMS, en conduisant :
* soit à retreindre de plus en plus le rôle des contributeurs et leur propre maîtrise des contenus qu'ils produisent (exemple de la production de tableaux de données qu'on décide de cantonner, via un interface de saisie, à un ou deux modèles de tableaux prédéfinis).
* soit à appauvrir de plus en plus les contenus (pour simplifier la gestion des images, supprimons la possibilité d'insérer une image dans un message de forum, par exemple).
* soit à rendre de plus en plus complexe l'édition du contenu, via des options, des syntaxes, des assistants etc. de plus en plus nombreux (Il devient tout aussi simple finalement de transformer le CMS en éditeur HTML avancé et de transformer les rédacteurs en experts en accessibilité)

- aussi loin qu'il puisse être poussé, ce contrôle ne garantit jamais l'accessibilité finale du contenu ainsi produit : une large part de l'accessibilité n'est pas gérable de manière automatisée (notamment tout ce qui relève de la pertinence du contenu)

C'est pourquoi, comme l'a rappelé Arsène, la production de contenus accessibles repose nécessairement sur une stratégie plus vaste, dont l'automatisation n'est qu'un aspect.

Au-delà, il faut surtout s'interroger sur la pertinence de cette notion de "site accessible" ou de "contenus accessibles" dans notre approche de l'accessibilité. <coming soon> Mais c'est une autre histoire, ça </>
Modifié par Laurent Denis (13 Feb 2008 - 08:07)

a écrit :
il faut surtout s'interroger sur la pertinence de cette notion de "site accessible" ou de "contenus accessibles" dans notre approche de l'accessibilité

C'est un peu pour ça que j'essaie de conceptualiser une approche que j'appelle "non-discriminante" qui tient compte de l'accessibilité comme facteur parmi d'autres et pas plus que ça. Pour les raisons évoquées dans ce post, il me semble que (option pessimiste) la courbe d' "accessibilité" d'un site suit pas à pas celle des "possibilités de ne plus l'être" (ou beaucoup moins) que génère les CMS. Donc, en gros, développer de l'accessibilité en tant que solutions techniques côté auteur ne fait que rattrapper la tendance à l'inaccessibilité que les CMS induisent. Pour caricaturer à l'extrême, je dirais que c'est une course perdue, parce qu'avec toujours un temps de retard.
Mettre en place des méthodes actives destinées aux producteurs de contenus est sûrement stratégiquement plus payant.

Bonjour,

Arsene a écrit :
C'est un peu pour ça que j'essaie de conceptualiser une approche que j'appelle "non-discriminante" qui tient compte de l'accessibilité comme facteur parmi d'autres et pas plus que ça.

Je ne comprends pas bien cette remarque, l'accessibilité est nécessairement, dans la perspective d'un contexte de production, un facteur parmis d'autre.
Ou dit plus simplement l'accessibilité pour l'accessibilité est un non-sens.

A moins que je n'ai pas compris ta remarque.

Arsene a écrit :
Pour les raisons évoquées dans ce post, il me semble que (option pessimiste) la courbe d' "accessibilité" d'un site suit pas à pas celle des "possibilités de ne plus l'être" (ou beaucoup moins) que génère les CMS.

Toute question de moyen mis à part, un CMS n'est pas un facteur aggravant pour l'accessibilité.
Il n'y à pas de corrélation entre l'outil (en loccurence un CMS) et l'accessibilité des contenus.
Il y avait les mêmes problèmes avant les CMS, via un simple textarea, qu'il y en a actuellement avec la généralisation des CMS.

Cela tient à la fois aux chaines de production qui se sont construites autour des CMS sur le mode "quick and dirty" qu'à l'effet "Dazibao" qui est consubstanciel au média.

Ce qui, effectivement, nous amène à :

Laurent Denis a écrit :
il faut surtout s'interroger sur la pertinence de cette notion de "site accessible" ou de "contenus accessibles" dans notre approche de l'accessibilité

Quoique je ne dirais pas les choses de la même manière :

Il n'y à pas vraiment à s'interroger sur ce qu'est un contenu accessible, on sait ce que c'est et sur le fond ce n'est pas négociable

En revanche la notion de site accessible est plus intéressante à interroger, ou plutôt engendre une question majeure : les contenus d'un site accessible doivent-ils, ou peuvent-ils, être tous accessibles (en laissant de coté la question de la permanence pour simplifier)

Et comme la réponse est clairement non (à la révolution culturelle près) les questions subsidiaires concernent les processus mis en place pour :

1. Gérer l'inaccessibilité
2. Informer /guider/ aider l'utilisateur qui, lui, à évidemment un besoin légitime de ne disposer que de contenus accessibles.

Toute proportion gardée c'est une problématique similaire à celle du plein emploi : tout citoyen est légitimement en droit d'exiger, dans nos démocraties, un emploi mais en même temps le "plein emploi" c'est de 5% à 7% de sans emploi...

Recontextualisé : tout utilisateur est en droit d'exiger des contenus 100% accessibles mais, en même temps, la vraie vie et les caractéristiques du média nous disent qu'un "site accessible" c'est probablement ........ de contenus innaccessibles.

Et pour remplir les pointillés de la phrase précédente il va nous falloir retrousser les manches de nos neurones parce que c'est très délicat, assez compliqué et que cela demande une petite "révolution culturelle".

Parmi toutes les bonnes raisons pour lesquelles c'est très délicat il y en à une, généralement sous-estimée, qui tient au rejet naturel par le corps social du "handicap" qui fait qu'il est extrèmement difficile d'envisager sereinement que nous ne pourrons compter que sur la "conscientisation" des intervenants pour rendre le web accessible.

Le handicap n'est pas un problème à "traiter" mais à "évacuer", et ce n'est pas qu'une idée reçue...

Par exemple, il est toujours surprenant de constater que nous n'acceptons pas, peut, ou mal, de devoir contraindre l'édition de contenus alors que nous acceptons sans aucun problème de diffuser des flux vidéos très dégradés.

Dans un cas il y à une limite technologique acceptée, dans l'autre des limites humaines refusées.

Pas parce que nous sommes "mauvais" mais simplement parce que c'est la fonction première de la construction sociale de rejeter la différence.

Dans cette perspective nous n'échapperons pas à devoir utiliser certaines formes d'exigences.

Laurent Denis a écrit :
- accroître le contrôle sur les contenus va à l'encontre du rôle le plus souvent dévolu aux CMS ...

Oui si et seulement si on ajoute que le rôle dévolu aux CMS n'est pas adéquat, mal pensé, et que les chaines de production qui y sont associées sont préhistoriques par rapport aux objectifs liés à l'accessibilité du web.

Et si on reconnait que la production de contenus web, telle qu'elle est actuellement pratiquée, tient plus de la production à la photocopieuse de fanzine mal foutus que de contenus de qualité.

Je parle là aussi dans une perspective disons "professionnelle", le web est aussi un gigantesque fanzine, c'est sa richesse, et ces contenus là ne sont évidemment pas concernés.

a écrit :
- aussi loin qu'il puisse être poussé, ce contrôle ne garantit jamais l'accessibilité finale du contenu ainsi produit ...

Oui si on fait une différence claire entre ce qui relève de l'exigence de ce qui est impossible de garantir.

Jean-Pierre
Modifié par jpv (14 Feb 2008 - 09:31)

Bonjour Jean-Pierre

Je pense que globalement j'ai dit la même chose mais avec d'autres mots (peut-être mal utilisés). Ça fait plus d'une heure et demie que j'essaie d'écrire une réponse assez complète mais c'est trop compliqué pour un matin
J'arrête pas de réécrire, de revenir sur tel ou tel point, etc... bref, j'arrête là.
Mais j'essaierai

Pour les curieux intéressés par cette réflexion sur les "limites", voici, tout nouveaux tout frais, 2 articles d'Elie Sloïm sur Openweb:
- Les nouveaux défis de l'accessibilité numérique: 1- la vision actuelle
- Les nouveaux défis de l'accessibilité numérique: 2- une autre vision de la démarche

Laurent Denis a écrit :
Pour les curieux intéressés par cette réflexion sur les "limites", voici, tout nouveaux tout frais, 2 articles d'Elie Sloïm sur Openweb:
- Les nouveaux défis de l'accessibilité numérique: 1- la vision actuelle
- Les nouveaux défis de l'accessibilité numérique: 2- une autre vision de la démarche

Bonjour Laurent,
tiens ça faisait un moment qu'il n'y avait pas eu d'articles publiés sur OpenWeb, c'est dommage que les contributions ne soient pas plus fréquentes.
Openweb est quand même une des premières références française en matière de promotion des standards (en tous cas pour ma part c'est par Openweb que j'y ai été sensibilisé). Peut-être parceque la nécessité de les promouvoir se fait moins sentir aujourd'hui?

PS: Désolé Poulpette de dévier du sujet initial

Il y a toujours beaucoup à faire pour expliquer (peut-être davantage que pour promouvoir). Mais disons que les gens sont parfois, par période, très ocupés ailleurs

L'important est que les publications puissent avoir lieu, surtout lorsqu'il s'agit d'enjeux essentiels (comme ici).

@ JP

JPV a écrit :
l'accessibilité est nécessairement, dans la perspective d'un contexte de production, un facteur parmis d'autre. Ou dit plus simplement l'accessibilité pour l'accessibilité est un non-sens.

Au vu de certains posts je dirais que ce n'est pas partagé par tout le monde. L'accessibilité est souvent perçue comme un but en soi.

JPV a écrit :
un CMS n'est pas un facteur aggravant pour l'accessibilité

Partiellement, si. D'abord en ce qu'il laisse supposer (je parle des solutions CMS qui s'annoncent comme conformes/valides/productrices de code accessible/etc) que le process est automatique, ensuite parce que le type et la richesse des contenus injectés s'accroît. Un formulaire récupérant un simple contenu texte qu'il injecte encadré d'un <p> ne crée pas de ravages... ajouter des images, des vidéos, des tables dans des tables, des listes dans des listes, des ceci et des cela multiplie exponentiellement les abus, erreurs, aberrations et inepties. Il y a un travail de formation et d'information tel que je tends à limiter les usages et raisonne maintenant en terme de "produit" plutôt que de "service" : en gros une interface produira un certain type de contenu pré-structuré pour un certain usage, elle n'offrira pas de solutions généralistes de mise en page/mise en forme. Ce qui requiert une définition précise des besoins de la part du client.

JPV a écrit :

En revanche la notion de site accessible est plus intéressante à interroger, ou plutôt engendre une question majeure : les contenus d'un site accessible doivent-ils, ou peuvent-ils, être tous accessibles

C'est là qu'on touche la notion de non-discrimination. Disons en gros que la discrimination consiste à définir un groupe d'utilisateurs et à lui appliquer un traitement spécifique, qu'il soit positif ou négatif. Reporté aux contenus ou applis web, la discrimination présuppose qu'un groupe d'utilisateur, défini selon un certain nombre de critères, n'a pas accès à ces ressources sans que cette impossibilité d'accès soit liée objectivement à des caractéristiques du groupe.
Concrètement, l'accès par login et mot de passe à des parties de ressources n'est pas une discrimination puisque les caractéristiques précisant qui a ce droit d'accès et qui ne l'a pas sont à la fois explicites et liées au statut de chaque utilisateur : fait-il partie ou pas du groupe discriminé. Inversement, rendre l'accès à des ressources difficile ou impossible à certains groupes indépendamment de critères objectivant la constitution de ce groupe est dommageable : par exemple les difficultés d'accès liées à un handicap ou à l'usage d'UA particuliers.
Donc à partir du moment où un groupe d'utilisateurs est confronté à un contenu dont tout ou partie est inconsultable ou inutilisable sans que ce groupe puisse être objectivement identifié comme n'ayant pas droit à..., il y a discrimination, et ce en dehors de toute notion d'accessibilité au sens restreint tel qu'on l'utilise ici. A l'inverse, on peut définir des parties de contenus pour lesquelles tel ou tel groupe aura un droit d'accès et pas tel autre. Le tout est que ce filtrage soit objectivable, cohérent, revendiqué et clairement annoncé (par exemple des utilisateurs de mobiles auront des ressources inaccessibles dans tel ou tel cas de figure).
On est là en plein dans la question.

JPV a écrit :
il est toujours surprenant de constater que nous n'acceptons pas, peut, ou mal, de devoir contraindre l'édition de contenus alors que nous acceptons sans aucun problème de diffuser des flux vidéos très dégradés.

Ah ben moi je suis pour les restrictions à l'édition de contenus. Comme dit plus haut, proposer des interfaces orientées "produits" et non "services" y contribue largement. La question n'est pas d'interdire ou pas d'interface CMS injectant de la vidéo, elle est de placer cette interface à certains endroits et pas à d'autres. Avec ça on retombe sur la notion de "scope" présente dans Uwem. Correctement construite, cette interface vidéo, porteuse de ses limites, propose du contenu à accès limité. Le tout est de définir clairement "limité à qui" et pourquoi.
C'était ça que je voulais dire par "Mettre en place des méthodes actives destinées aux producteurs de contenus est sûrement stratégiquement plus payant."


J'espère avoir été un peu plus clair
Modifié par Arsene (14 Feb 2008 - 20:01)

a écrit :
la notion de "scope" présente dans Uwem

ça ne serait pas plutot dans WCAG 2 ?