HTML5 Alternative Text, and Authoring Tools

Henri Sivonen wrote:

> I'm curious why accessibility advocates
> want to bake some of that into the notion of
> conformance on the axis of machine-checkable
> HTML5 syntax instead of promoting conformance
> on  the accessibility evaluation axis on its own right.

> So far, I've come up with two possible explanations:

>  1) It's about assuming that a notion of "Valid HTML5"
> is more appealing/marketable than a notion of
> "A[A][A] level conformance to WCAG 2.0".

This is certainly true.  It is always easier to sell

    "Do X correctly"
than
    "Do X correctly while also doing Y".

For X==HTML, "Do X correctly"=="Write Valid HTML", and any addon
(whether it be accessibility or house style) is harder to remember and
enforce.

> ... wouldn't it mean that there'd be people
> who'd seek to satisfy a validator without
> necessarily doing good to accessibility

This relates to a third reason -- that things which can be checked
automatically are much easier to enforce, and therefore much likelier
to happen.

But yes, it is a problem, and we do have to weigh the benefit of
easier enforcement against the detriment of more loophole-using.

>  2) The notion that a document could be deemed
> "correct" on *some* evaluation axis without *also*
> being accessible is somehow offensive.

Close.

No one would object to a claim that Headings were used in a correct
manner, even if a document weren't fully accessible.

But Validity is (in practice) treated as *complete* correctness,
because it includes everything that can be easily and automatically
checked.

Leaving out accessibility is worse than invalid nesting -- it just
isn't as easy to check.  So making it even harder to check seems like
a step backwards.

Note that by this reasoning, it would be OK to leave it out of an
image in a figure *if* the caption were defined to provide that
information in the absence of an alt, because that would still be
machine-checkable.

> I think it isn't productive to deny non-accessibility
> evaluation axes to use cases that aren't accessible

Agreed -- so long as it is clear that only some axes are being
evaluated.  Thus the suggestion of

"This page is valid HTML5 except ..."

> Validator.nu gives the alt issue more prominence
> than HTML 4 validators ever have.

Agreed.  Though I might prefer a slight tweak.  Coming after "Be lax
about ..." "Disrespect..." makes it seem like a bad thing.  Perhaps
change to

X   Be strict about HTTP Content-Type
        title=Respect MIME RFCs
X   Show Image Report
        title=Run accessibilty check on textual alternatives to images
    Show Source
        ...

> ... HTML 5 shouldn't *require* HTML5
> validators to have particular additional features in
> addition to the HTML 5 validation function

Agreed.  But ideally, accessibility would become more checkable,
rather than less so.

I would therefore have less of a problem saying that validators which
don't do this must indicate the limitation when (and if) they report
Validity.  For example, instead of saying:

    "This document is Valid HTML",

they could only say

    "This document is Valid HTML with the possible
    exception of features which this tool did not check.
    Unchecked Features include:
    ... "

and a requirement that alt usage be listed in the exceptions.  The
list should of course include other features that are also hard to
fully check, but might reasonably be limited to those where there is
at least demonstrated Good Practice among validators -- and alt usage
now qualifies.

-jJ

Received on Sunday, 4 May 2008 20:28:06 UTC