Recently, Anne van Kesteren demonstrated
a
nice technique with the XHTML
2.0 media attribute designed to deliver a contact form to screen users, while giving
a postal address for print users. Faruk Ates also published an interesting article
about XHTML
2.0 and Google, specifically focussing on the potential abuse of
the media attribute to hide content from screen users, but not from Google.
However, this got me thinking about some of the accessibility issues involved
with this technique.
Take a look at Anne’s example:
<section> <h>Contact</h> <div media="screen"> Contact form to be inserted here. </div> <div media="print"> <address layout="relevant">Anne van Kesteren Crosestijn 4629 …</address> </div> </section>
As you can see, this clearly provides suitable alternate content for users
depending on whether they’re using a screen medium, or print medium. However,
what about other media
types like braille, embossed, handheld, projection,
speech, tty, tv or any other media? They get nothing!
Clearly, the intention of this example is that the contact form is not suitable
for any static media (embossed and print), while the postal address is. There
is also no reason why a postal address isn’t suitable for all media. One solution,
and currently the only usable solution, is to explicitly list all suitable media
in the attribute (it’s a comma separated list). However, what happens when CSS
extends the list of possible media in the future? Would the media attributes
then need to be updated to reflect this?
Another solution I can think of would be to allow for the CSS media groups to be used instead, but AFAICT, that’s not possible at this stage. For example, the above example could become:
<section>
<h>Contact</h>
<div media="interactive">
Contact form to be inserted here.
</div>
<div media="all">
<address layout="relevant">Anne van Kesteren
Crosestijn 4629 …</address>
</div>
</section>
A solution would be to allow the media attribute values to also be specified like this:
media="not screen,projection"That way, you can restrict things based on both white and blacklisting procedures, allowing effectively anything you’d like.
In purely theoretical terms that’s a non-issue. The XHTML 2 draft references CSS 2 (not, incidentally, CSS 2.1, so it’s aural not speech) so the list of permitted media types can not change without either a change to XHTML 2 or to CSS 2. Once XHTML 2 is finalised any documents written as XHTML 2 will have a well defined set of media to work with.
Of course that’s just the theory, in practice any XHTML 2 implementations will probably, in true tag soup fashion, support whatever values for media types are in the latest version of CSS (and maybe others, e.g. Aural for legacy reasons; whatever Google decides to invent…) and the problem you describe becomes very real.
Steve, the XHTML 2.0 WD currently allows for rather flexible specification of the media attribute’s value. It is limited to use keywords from the media collection, but it already allows specified content, for instance, you can specify it to apply only to screens with a window-size of at least 800 pixels.
It’s already rather flexible. Sadly not well-documented yet how flexible, but it’s more than just the current comma-separated list and no more.
What about a value called “otherwise”?
Faruk, the current XHTML 2.0 draft doesn’t seem to be that flexible, unless you can refer me to the section you’re talking about. Although, you did remind me of CSS3 Media Queries. I don’t know why I didn’t think of it before, as it allows queries like
media="not print, not embossed", which could be used in place ofmedia="screen"in the above examples, although it’s only a candidate recommendation at this stage.Lachlan, it might be that I’m confusing things. I blame @media and Douglas Bowman (with a wink, nudge and thanks for the plug to the latter, mind you).
During @media I was reminded of the media attribute as it was used in a presentation or two, and it showed how to do complex media queries. However, I can’t quite recall whether that was a CSS3 example or an XHTML 2.0 example. I remember, in any case, that I didn’t remember (at that time) such a complex example to be listed or even discussed in the XHTML 2.0 WD, so you may be right that it’s only part of the CSS3 Media Queries module.
Also, “it’s only a CR at this stage” — XHTML 2.0 is still a Working Draft, so it’s even further off. 🙂