Archive for August, 2007
Thursday, August 23rd, 2007
This article is a French translation of the article Why the Alt Attribute May Be Omitted.
La spécification de l'attribut alt a été retravaillée récemment, afin d'améliorer sa définition, en incluant une explication en profondeur de comment fournir le texte alternatif le plus approprié avec de réelles exigences éditoriales.
La spécification décrit des situations où le texte alternatif doit être précisé, où un attribut alt vide doit être utilisé et où, de façon plus sujette à controverse, l'attribut alt peut parfaitement être omis. Cette omission peut sembler être sujette à controverse, parce que au premier regard, cela ressemble à une tentative pour justifier la mauvaise pratique, contraire aux principes de l'accessibilité, qui consiste à oublier l'attribut alt ... Et à jeter un pavé dans la mare. C'est une confusion malheureuse qui nécessite qu'on s'y arrête un instant pour balayer les doutes qu'elle pourrait susciter chez bien des gens. Bien que cela puisse paraître rétrograde, la situation est ainsi bien meilleure.
Il y a bien des cas où le texte alternatif est tout simplement indisponible et où il y a peu de choses que l'on puisse faire pour remédier à la situation. Par exemple, la plupart des utilisateurs de sites de partage de photos comme Flickr n'auraient certainement aucune idée de quoi écrire comme texte alternatif, même si Flickr leur en offrait la possibilité. Et même si, bien sûr, tout le monde s'accorde à dire que si ce serait formidable si, comme la spécification l'encourage, tous les utilisateurs le faisaient, la plupart ne le feront tout simplement pas.
Le problème que nous venons de soulever est le suivant : que devons-nous faire dans le cas où aucun texte alternatif n'a été spécifié et où il reste virtuellement impossible à définir ? De nombreux systèmes actuels tentent de satisfaire la recommandation actuelle en matière de texte alternatif en générant ce texte à partir des métadonnées des images.
Flickr, par exemple, répète le titre de l'image ; Photobucket semble combiner le nom du fichier image, le titre et le nom de l'utilisateur - et Wikipédia reproduit de façon redondante la légende de l'image. Le problème de ces approches est qu'aucune d'entre elles ne fournit une information additionnelle utile à propos de l'image et, dans certains cas, cela est pire que de ne fournir aucun texte alternatif.
Le bénéfice que l'on peut retirer de permettre l'omission du texte alternatif, plutôt que de nécessiter une valeur vide est que cela permet de créer une distinction claire entre une image qui n'a pas de texte alternatif (comme une icône où une représentation graphique du texte environnant) et une image qui fait partie intégrante du contenu, mais pour laquelle aucun texte alternatif n'est disponible. Il a été dit que Lynx et Opera faisaient déjà cette distinction. Pour des images qui n'ont pas d'attribut alt, Lynx montre le nom du fichier et Opera le texte "Image", mais aucun des deux ne montre quoi que ce soit pour les images dont l'attribut est laissé vide. Il reste à déterminer si cette disctinction est effectivement utile dans l'affichage du contenu du "monde réel" et il y a réellement un débat à mener si vous avez des preuves à avancer.
On a suggéré que retirer la présence inconditionnelle de l'attribut alt affecterait la capacité des validateurs à montrer leurs erreurs aux utilisateurs et retirerait un bon outil de promotion de l'accessibilité. Cependant, utiliser les erreurs de validation comme un outil d'évangélisation de l'accessibilité n'est certainement une bonne façon d'envisager cette problématique.
Tandis qu'il est en effet très utile pour les auteurs de savoir quand ils ont oublié par erreur un attribut alt en cherchant à les obliger à l'utiliser de façon inconditionnelle, utiliser un outil aussi éculé qu'un validateur est contre-productif, car il encourage l'utilisation de textes générés automatiquement de pauvre qualité. Paralèllement, rien n'empêchera les outils de validation et d'édition web de signaler ces erreurs aux auteurs si tel est leur bon plaisir.
Aucun des bénéfices de l'accessibilité n'est perdu en acceptant le fait qu'il est impossible de forcer tout le monde à fournir un texte alternatif et en rendant l'attribut alt optionnel pour pouvoir s'assurer de la conformité d'un document. Personne ne proclame que la conformité au HTML 5 est équivalente à la conformité avec les recommandations d'accessibilité. Il y a de nombreuses choses qui sont considérés conformes techniquement en HTML, mais qui demeurent "inaccessibles" si elles sont mal utilisées. Rendre l'attribut alt techniquement optionnel ne se dresse pas contre les recommandations d'accessibilité, pas plus qu'il n'a un quelconque impact sur l'évangélisation de l'accessibilité. Il s'agit simplement d'accepter la réalité de la situation à laquelle nous faisons face, dans l'espoir de réduire la prolifération des textes alternatifs de mauvaise qualité générés automatiquement.
Posted in Browsers, Elements, Processing Model, WHATWG | 2 Comments »
Thursday, August 23rd, 2007
The specification
of the alt attribute was recently worked on to thoroughly
improve its definition, including an in depth explanation of how to provide
appropriate alternate text, with clear authoring requirements.
The requirements describe situations where alternate text must be provided,
where an empty alt attribute must be used and, most controversially,
where the alt attribute may be omitted entirely. This
is controversial because at first glance, it seems like an attempt to endorse
the bad and inaccessible practice of omitting the alt attribute,
and thus yet another slap in the face for accessibility. That is an unfortunate
misconception that needs to be carefully examined to settle any concerns people
have. Although it may seem backwards, the situation is actually much more
positive.
There are many observed cases where alternate text is simply unavailable and
there’s little that can be done about it. For example, most users of photo
sharing sites like Flickr wouldn’t have a
clue how or why to provide alternate text, even if Flickr provided the ability.
While everyone agrees that it would be wonderful if all users did – indeed,
the spec strongly encourages that – most users simply won’t.
The problem being addressed is what should be done in those cases where no alt text
has been provided and is virtually impossible to acquire. With the current
requirement for including the alt attribute in HTML4, it has been
observed that many systems will attempt to fulfil the requirement by generating
alternate text from the images metadata.
Flickr, for example, repeats the images title; Photobucket appears
to combine the image’s filename, title and the author’s username; and Wikipedia
redundantly repeats the image caption. The problem with these approaches is
that using such values does not provide any additional or useful information about
the image and, in some cases, this is worse than providing no alternate text
at all.
The benefit of requiring the alt attribute to be omitted, rather
than simply requiring the empty value, is that it makes a clear distinction
between an image that has no alternate text (such as an iconic or graphical
representation of the surrounding text) and an image that is a critical part
of the content, but for which not alt text is available. It has
been claimed that Lynx and Opera already use this distinction.
For images without alt attributes Lynx shows the filename and
Opera displays "Image", but neither show anything for images with empty alt attributes.
It is still somewhat questionable whether this distinction is actually useful
and whether or not browsers can realistically make such a distinction with
real world content, and that is certainly open to debate if you have further
evidence to provide.
It has been suggested that taking away the unconditional requirement for the alt attribute
will affect the ability of validators to notify authors of their mistakes and
take away a useful tool for promoting accessibility. However, using validation
errors as an accessibility evangelism tool is not necessarily the only, nor
the best, way to address the issue.
While it is indeed very useful for authors to know when they have mistakenly
omitted an alt attribute, attempting to unconditionally enforce
their use, using a tool as blunt as a validator, is counter productive since
it encourages the use of poor quality, automatically generated text. Besides,
nothing will prevent conformance checkers and authoring tools from notifying
authors, if they so desire.
No practical accessibility benefits are lost by conceding the fact that you
cannot force everyone to provide alternate text and making the alt attribute
optional for the purpose of document conformance. No-one is claiming that conformance
to HTML5 equates to conformance with accessibility requirements. There are
lots of things that are considered technically conforming in HTML, yet still
inaccessible if used poorly. Making alt technically optional doesn't stand
in the way of accessibility requirements, nor greatly impact upon accessibility
evangelism. It just acknowledges the reality of the situation in the hope of
reducing the prevalence of poor quality, automatically generated alt text.
Posted in Browsers, Elements, Processing Model | 46 Comments »
Tuesday, August 21st, 2007
Ian Hickson announced on the WHATWG and public-html mailing lists that he's written a tool that exposes his list of open issues:
In response to the concerns over the lack of transparency that have
recently been expressed both in these mailing lists and on blog posts, I
have written a tool that exposes the issues I have on my list:
http://www.whatwg.org/issues/
You can even vote for an issue to indicate that it should be made a
priority (to do that, you'll have to have sent an e-mail that ended up
on that list, as I use that as a way to prevent random spammers from
trying to use this web app).
There's also a page that shows the current 20 most-voted-for issues:
http://www.whatwg.org/issues/top
That page also contains some notes on what I'm likely to work on next,
though this information isn't necessarily accurate.
In addition to the above, you can also get a notification of every change
to the spec using one of the following methods:
You can follow this twitter feed (you can even subscribe to this with
your mobile phone so that you get text messages for every checkin):
http://twitter.com/WHATWG
You can subscribe to this mailing list:
http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org
You can browse recent changes to the spec here:
http://html5.org/tools/web-apps-tracker
If anyone wants to volunteer to summarise changes and post announcements,
please just do it! Don't ask for permission, ask for forgiveness! I'm not
sure what the process is to post to the HTML working group blog, but you
can post to the WHATWG blog just by signing up and writing a blog post
(just tell Lachlan afterwards so he can actually post it, we have that
limited to certain users because spammers were abusing the blog). You can
also post announcements to the WHATWG twitter feed using the form on the
front page of whatwg.org.
Cheers,
Posted in WHATWG | Comments Off on Seeing the open issues
Monday, August 20th, 2007
This is a French translation of the article: Presentation: How HTML5 can be used today.
Hier, j'ai fait une présentation pour Creuna puis au Geek Meet sur la façon dont HTML 5 peut être utilisé aujourd'hui. La présentation était faite en Suédois, et c'est pourquoi les diapos sont disponibles en Suédois.
L'audience était essentiellement composée de personnes dont le métier est de créer des sites web.
La discussion qui a suivie était intéressante, mais elle n'a pas été enregistrée et je ne peux pas me souvenir de toutes les questions qui ont été posées, malheureusement. En voilà toutefois quelques unes qui me reviennent en mémoire :
- Quand est-ce que HTML 5 sera effectivement utilisé par les développeurs web ?
- Ca dépend de vous.
- Quand est-ce que HTML 5 sera terminé ? Quels sont les délais prévus ?
- Le tout est de savoir à quelle vitesse les différents navigateurs l'implémenteront. Le groupe de travail du W3C pour HTML 5 indique qu'une recommandation pour ce langage sera disponible pour 2010, mais je ne pense pas qu'il soit réaliste de penser qu'à cette date les navigateurs l'auront implémenté totalement et correctement. Un délai de 15 ans me semble plus réaliste, mais cela ne veut pas dire pour autant que vous avez besoin d'attendre 15 ans pour utiliser HTML 5.
- Quel est l'intérêt d'utiliser Web Forms 2.0 plutôt que d'utiliser les formulaires HTML 4 et du Javascript ?
- Moins de travail pour les développeurs et un meilleur rendu pour les utilisateurs. Par exemple, utiliser un <input type=email> signifie pour le développeur qu'il n'a pas à écrire du Javascript côté client pour valider qu'il s'agit d'une adresse email et pour l'utilisateur qu'il peut choisir un mail dans son carnet d'adresse personnel (quelque chose qu'il est impossible d'implémenter en Javascript).
- Sera-t-il possible de style les nouveaux contrôles de formulaire avec du CSS ?
- Il sera sans doute possible de le faire de la même façon qu'il est actuellement possible de le faire. L'icône dans le contrôle email est ajoutée par Opera quand le contrôle de formulaire est stylé d'une façon ou d'une autre (je style en général le fond en blanc pour la faire apparaître).
- Peut-on styler ou modifier les messages d'erreur du formulaire ?
- Je ne suis pas sûr que vous puissiez les styler, mais vous pouvez cependant en changer le texte avec Javascript ou réécrire le mécanisme qui signale l'erreur et créer le votre avec Javascript.
- Est-il vrai que HTML 5 permettra l'utilisation de <font> ?
- Non, les développeurs ne pourront pas utiliser <font>. Cependant, les éditeurs WYSIWYG seront autorisés à émettre des balises <font>. Ils devront s'identifier avec une balise <meta>. Cette problématique a reçu beaucoup de feedback et pourrait être modifiée.
- Avez-vous besoin d'être compatible en ce qui concerne l'utilisation de /> ou > ?
- Non
- Si vous ne spécifiez pas quelle est la version d'un document HTML, comment pourrez-vous redéfinir le comportement d'un élément, plus tard, dans HTML 6 ?
- Il n'y a pas besoin de préciser la version : les navigateurs traitent tous les documents HTML de la même façon, sans prêter attention à la version à laquelle ils déclarent appartenir. Un bon exemple de cela est la balise <plaintext>, qui a été dépréciée depuis la première version de HTML et qui est encore supportée dans tous les navigateurs, même si vous spécifiez une version HTML 4 par le DOCTYPE.
- Est-ce que HTML 5 déprécie quelque chose ?
- Rien n'est déprécié en fait, mais certaines choses sont totalement interdites. Par exemple, l'élément <u> n'est pas autorisé dans des documents HTML 5 conformes. Mais les navigateurs continueront cependant à le supporter.
- Est-ce que html5lib peut parser n'importe quelle soupe de tags ?
- Oui.
- Est-ce que cela signifie que l'on peut convertir n'importe quel vieux document HTML en XML en la passant à la moulinette de html5lib ?
- Oui.
- Est-ce qu'on peut utiliser le tag <svg> dans HTML 5 ?
- Non, vous ne pouvez pas utiliser les espaces de nom (namespaces) en HTML 5. Vous pouvez cependant inclure du SVG dans XHTML5 puisqu'il s'agit simplement de XML.
Posted in WHATWG | 1 Comment »
Monday, August 20th, 2007
A cross-browser
implementation of Web
Forms 2.0
has been released. The W3C HTML Working Group is now
reviewing the Web Forms 2.0 specification to serve as a
basis for the next version HTML (as everyone knows). Some discussion on
the HTML WG mailing
list regarding the WF2 specification has been at times ignorant of the
content of the specification and what it actually enables authors to
do.
Hopefully by using this implementation and examining its associated test
suite,
the meaning of the specification will be clarified, and members of the
HTML WG will be more educated so as to more constructively review it.
I started work on this project with an standalone
implementation of the repetition model, but I have since expanded it to
include other WF2 features as well. I developed this library on the job
for incorporation into the various development projects I was working
on; I have found the functionality provided by WF2, especially the
repetition model and the form validation model, to greatly ease
development. Try using it in your own projects and see for
yourself, and then drop a line to WHATWG and the HTML WG with
your feedback on what works well and what needs to be improved.
This implementation works in Firefox 1+, MSIE 6+, and Safari
2+ (Opera,
of course, has a native implementation). For more information on the implemented features, see the implementation
details. This implementation will follow the HTML 5
specification that evolves from the work done by the HTML Working Group.
Posted in Forms | 1 Comment »