HTML 5

There has been a certain amount of controversy over the supposed date of 2022 for HTML 5 to be “finished”. It is somewhat important to realise the significance that should be attached to this date:

None at all

OK, strictly speaking that’s not quite true, but it’s a pretty good approximation to the truth. What really matters is when browsers ship HTML5 features. Given that’s already happening, there is really no cause for alarm. By 2022 we hope to have a full testsuite and two full implementations but then we also expect to see products shipping with features from HTML 6.

[Read more →]

Welcome to a new semi-regular column, “This Week in HTML 5,” where I’ll try to summarize the major activity in the ongoing standards process in the WHATWG and W3C HTML Working Group.

The biggest news is the birth of the Web Workers draft specification. Quoting the spec, “This specification defines an API that allows Web application authors to spawn background workers running scripts in parallel to their main page. This allows for thread-like operation with message-passing as the coordination mechanism.” This is the standardization of the API that Google Gears pioneered last year. See also: initial Workers thread, announcement of new spec, response to Workers feedback.

Also notable this week: even more additions to the Requirements for providing text to act as an alternative for images. 4 new cases were added:

1. A link containing nothing but an image
2. A group of images that form a single larger image
3. An image not intended for the user (such as a “web bug” tracking image)
4. Text that has been rendered to a graphic for typographical effect

Additionally, the spec now tries to define what authors should do if they know they have an image but don’t know what it is. Quoting again from the spec:

If the src attribute is set and the alt attribute is set to a string whose first character is a U+007B LEFT CURLY BRACKET character ({) and whose last character is a U+007D RIGHT CURLY BRACKET character (}), the image is a key part of the content, and there is no textual equivalent of the image available. The string consisting of all the characters between the first and the last character of the value of the alt attribute gives the kind of image (e.g. photo, diagram, user-uploaded image). If that value is the empty string (i.e. the attribute is just “{}“), then even the kind of image being shown is not known.

• If the image is available, the element represents the image specified by the src attribute.
• If the image is not available or if the user agent is not configured to display the image, then the user agent should display some sort of indicator that the image is not being rendered, and, if possible, provide to the user the information regarding the kind of image that is (as derived from the alt attribute).

See also: revision 1972, revision 1976, revision 1978, revision 1979, Images and alternate text.

Other interesting changes this week:

• revision 1951: define window.top
• revision 1956: “User agents must not run executable code embedded in the image resource.”
• revision 1958: more notes on what is a valid image (a surprisingly difficult question)
• revision 1965: allow <a> elements to straddle paragraphs
• revision 1998: define what happens when you set onclick='' on a document outside a Window
• revision 1999: define javascript: in Window-less environments
• revision 2001: define ‘directionality’ in terms of the dir='' attribute for cases where the 'direction' property has no computed value
• revision 2002: define processing for the second argument to getDataURL() for image/jpeg
• revision 2004: specify how to handle transparent images in the toDataURL() method
• revision 2008: make patterns required in the <canvas> API
• revision 2016: when <script type=''> is given, it must match the type of the script, even if the script is Javascript
• revision 2019: remove autosubmit='' from the <menu> element

Tune in next week for another exciting episode of “This Week in HTML 5.”

[Read more →]

There is now a new release of the Validator.nu HTML Parser. Change highlights:

• Adds optional support for heuristic encoding sniffing using the ICU4J sniffer, jchardet or both.
• Adds support for rewinding and reparsing when becoming confident about the character encoding and the tentative encoding was wrong.
• Performs encoding name matching per spec instead of using the JDK mechanism.
• Implements spec changes up until just before SVG and MathML support. (Those will merit 1.1 or something.)
• Warning: The semantics of the doctype token have changed in case you have your own token handler (unlikely).

[Read more →]

Version 1.0.6 of the Validator.nu HTML Parser has been released. The new version fixes a crasher bug in bytes to characters conversion, works around a crash when the ICU4J 3.8.1 UTF-7 decoder is in the classpath, improves error message wording and brings errors and warnings pertaining to legacy encodings up-to-date per the current HTML 5 draft.

This update is highly recommended for all applications that use the parser by giving it an URI or an InputStream. For applications that give the parser a Reader the update is not necessary.

[Read more →]

This is a Polish translation of this article: Why the Alt Attribute May Be Omitted.

Prace prowadzone ostatnio nad specyfikacją atrybutu alt mają na celu gruntowną poprawę jego definicji, m.in. dokładne wyjaśnienie sposobów tworzenia poprawnego tekstu zastępczego oraz jasne sprecyzowanie wymagań autorskie.

Wymagania te określają sytuacje, w których konieczne jest użycie tekstu zastępczego, zastosowanie pustego atrybutu alt oraz, co najbardziej zaskakujące, kiedy atrybut alt można całkowicie pominąć. Jest to kwestia kontrowersyjna, ponieważ na pierwszy rzut oka wygląda to na próbę zachęcania do złego i sprzecznego z zasadami dostępności zwyczaju pomijania atrybutu alt, co wydaje się być kolejnym policzkiem dla dostępności w sieci. Jest to niewłaściwe rozumowanie, które należy przeanalizować ze szczególną uwagą tak, aby rozwiać wszelkie wątpliwości, jakie mogą powstać. Choć taka sytuacja wydawać się może uwstecznieniem jest to w rzeczywistości bardzo pozytywny zabieg.

W wielu sytuacjach tekst zastępczy jest po prostu niedostępny i nic nie można na to poradzić. Przykładowo, większość użytków serwisów wymiany zdjęć takich jak Flickr nie miałoby pojęcia jak, ani dlaczego, należy dołączyć tekst zastępczy, nawet gdyby Flickr dawał im taką możliwość. Chociaż wszyscy są zgodni co do tego, że wspaniale byłoby gdyby wszyscy użytkownicy stosowali tekst zastępczy (specyfikacja wyraźnie to zaleca), to większość z nich po prostu tego nie zrobi.

Należy zastanowić się nad problemem co zrobić w sytuacji kiedy tekst alt jest niedostępny i nie ma tak naprawdę sposobu żeby go wstawić. Przy obecnych wymaganiach stosowania atrybutu alt w HTML4 zaobserwować można próby spełnienia tego wymagania przez systemy, które podejmują próbę utworzenia tekstu zastępczego w oparciu o metadane obrazu.

Flickr na przykład powtarza tytuł obrazu; Photobucket najwyraźniej łączy ze sobą nazwę pliku, jego tytuł i nazwę autora; z kolei Wikpedia niepotrzebnie powtarza podpis pod obrazem. Problemem wynikającym z takiego podejścia jest to, że stosowanie takich wartości nie dostarcza ani dodatkowych ani użytecznych informacji dotyczących obrazu, co w niektórych przypadkach jest gorsze niż całkowity brak tekstu zastępczego.

Korzyścią płynącą z wymogu opuszczenia atrybutu alt zamiast pozostawienia po prostu pustej wartości jest jasne rozróżnienie pomiędzy obrazem, który nie posiada tekstu zastępczego (jak np. reprezentacja otaczającego tekstu w postaci grafiki lub ikony) a obrazem będącym kluczowym elementem zawartości, dla którego tekst zastępczy nie jest dostępny. Podobno Lynx i Opera stosują już takie rozróżnienie. Przy obrazach bez atrybutu alt Lynx wyświetla nazwę pliku a Opera pokazuje napis “Obraz”, jednak żadne z nich nie wyświetla niczego przy obrazach z pustym atrybutem alt. Wciąż niewiadomo do końca czy takie rozróżnienie jest naprawdę użyteczne oraz czy przeglądarki mogą realistycznie je stosować. Kwestia ta jest otwarta do dyskusji jeżeli tylko ktoś dysponuje argumentami.

Sugeruje się też, że zrezygnowanie z bezwarunkowej konieczności stosowania atrybutu alt wpłynie na zdolność walidatorów do powiadamiania autorów o błędach i odbierze nam narzędzie pomocne w promowaniu dostępności. Jednak wykorzystywanie komunikatów o błędach walidacji jako narzędzia oświatowego nie jest ani jedynym ani najlepszym rozwiązaniem problemu.

O ile autorzy lubią wiedzieć kiedy przypadkowo pominęli atrybut alt, to bezwarunkowe wymuszanie użycia tego atrybutu przy wykorzystaniu tak prymitywnego narzędzia jakim jest walidator daje dokładnie przeciwne wynik, ponieważ zachęca do korzystania z generowanych automatycznie tekstów kiepskiej jakości. Zresztą nic nie powstrzyma narzędzi autorskich i sprawdzających zgodność ze standardami przed powiadomieniem autorów jeśli będą sobie tego życzyć.

Przyznając, że nie da się zmusić każdego do stosowania tekstu zastępczego i czyniąc atrybut alt opcjonalnym w standardach dokumentu nie traci się żadnych praktycznych korzyści płynących z dostępności. Nikt nie twierdzi, że zgodność z HTML5 jest tym samym co zgodność ze wymogami dostępności. Wiele rzeczy uważa się za spełniające techniczne wymogi HTML, a jednak ich niewłaściwe stosowanie czyni je niedostępnymi. Uczynienie atrybutu alt opcjonalnym nie jest sprzeczne z wymogami dostępności ani nie ma wielkiego wpływu na ich propagowanie. Opisuję tu tylko rzeczywistość mając przy tym nadzieję na zmniejszenie powszechności automatycznie generowanego tekstu alt kiepskiej jakości.

[Read more →]