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 »
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
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 »
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 »
There is now an open-source implementation of the HTML5 parsing algorithm in Java 5: the Validator.nu HTML Parser. The parser can be used as a drop-in replacement for the XML parser in applications that use SAX, DOM or XOM APIs to read XHTML 1.x content with an XML parser.
Posted in Conformance Checking, Processing Model, Syntax | Comments Off on Implementation of the HTML5 parsing algorithm in Java