[Irl-dean] False Accessibility Developers

Barry McMullin mcmullin at eeng.dcu.ie
Mon Mar 27 20:34:02 IST 2006

On Mon, 27 Mar 2006, Eoin Campbell wrote:

> We have developed a number of public sector websites and made
> them as accessible as we believe possible, but other peoples
> opinions may differ.  The following are areas where people have
> complained about sites we developed, or we ourselves are not
> certain what the best approach is.

Eoin is quite right to point at the sometimes uncertain or
subjective nature of web accessibility evaluation.  This is a
real problem.

This is very current with me because we have just spent an
extended period, as part of the Support-EAM project, minutely
comparing three different "web accessibility labelling" schemes
currently in operation in three different EU states.  The good
news is that we found a lot of commonality between them; however,
we did also find some notable divergences.  It is clear that
even among people who are really very competent in the area there
can still be honest disagreement.

In principle, WCAG 2.0 should improve this situation - at least
some of the ambiguous or dated aspects of WCAG 1.0 are due to be
addressed.  However ... WCAG 2.0 does still seem to be some way
away from finalisation.

In the meantime, it might be no harm to have some "local"
discussion here on irl-dean, just exchanging our own opinions on
what best practice (or best interpretation of WCAG) would be in
different practical situations. So, with that in mind, and
conscious that I'm going to differ from some of the other
reactions already posted, here's my own tuppence worth on the
specific questions raised by Eoin:

> 1. HTML vs. XHTML
> Since MS-IE6 and Lynx don't support XHTML properly, we still recommend
> HTML 4.01 Strict over XHTML 1.0 Strict for public websites, for better
> backward compatibility.
> Many believe using HTML in 2006 when XHTML is around since 1999 is not
> accessible.

This has been intensely debated back and forth several times on
the W3C wai-ig list (and probably elsewhere).  My own take is:

- I have seen *no* documented accessibility benefit to using
  XHTML over HTML 4.

- There *are* documented drawbacks, both accessibility and
  otherwise, to the hacks that are currently commonly used to
  deploy XHTML at the moment. (They *can* be worked around
  ... but why bother?)

- That said, *valid* code of just about any kind (XHTML or
  HTML) should trump invalid code of any kind (so valid XHTML is
  clearly preferable to invalid HTML; but equally, valid HTML is
  clearly preferable to invalid XHTML).

- Of course, all this is independent of the use of XHTML (or more
  generally XML) *internally* on the server-side.

- Eamon mentioned that he was in favour of XHTML on the basis
  that "... content can be parsed and machine-processed as XML
  later on" but I think this is confusing the HTML/XHTML issue
  either with the tag soup/valid code issue or with the internal
  server representation/client side delivery representation
  issue. *Valid* HTML can be trivially transcoded to XHTML at any
  time in the future if and when a scenario arises where there
  actually is some reason for doing that.

- In short, for the moment, the use of XHTML on the client-side
  seems to me to be mainly a fashion statement that has little to
  do with accessibility or even technical need. So I would be
  with Eoin, in advocated HTML 4.01 for delivery to the client side.

> 2. Strict vs. Transitional
> Should accessible websites comply with the Strict variant of the DTDs
> rather
> than transitional?
> I think that, as a minimum, the HTML templates used to maintain the site
> should,
> so that common boilerplate areas are as accessible as possible.

I would argue that, in marked contrast to the debate between HTML
and XHTML, there is a clear accessibility benefit to preferring
Strict over Transitional: many of the things deprecated in
Transitional are precisely to do with accessibility.

Eamon argued that sometimes "Transitional is right because
the page wants to do something Strict won't allow"; but I'm
finding it hard to come up with an example. Could you be a bit
more specific Eamon?

Mind you, requiring a strict flavour of HTML does not *in itself*
guarantee that it will be used appropriately.  For example,
strict might be said to encourage proper separation of
presentation from content; but it certainly can't compel it.  It
is perfectly possible to take a HTML transitional page and
mechanically replace many of the deprecated presentational
attributes with equivalent style attributes - which may then allow
it to conform to HTML strict instead. But it is not one iota more
accessible for that.

> 3. Image formats
> Are GIF/JPEG images allowed instead of PNG?
> Again, for maximum backward compatibility, I think yes, but others
> disagree,
> since PNG is an open W3C standard, and GIF/JPEG are not.

A jesuitical reading of WCAG 1.0 checkpoint 11.1 would probably
say to prefer PNG; but, in my experience, the practical impact
of this particular choice on accessibility is exactly zero.
Accordingly I would say that even discussing this as an
"accessibility" issue is the sort of thing that gives
accessibility a bad name.

> 4. Image alt text
> Should every image have alt text?
> I think not, but some people do.
> (Especially those who only half-understand the WCAG guidelines, in my
> experience)

Um - clarification please, Eoin?

Do you mean "should every image have an alt *attribute*"?  If so,
my answer is unequivocally *yes* it should (not least because it
is required for validity - but that, in turn, was motivated by
accessibility arguments).

In the other hand, if you mean "should every image have a
*non-empty* alt attribute", then I would certainly agree that the
answer is "no".  There are many cases where an empty alt
attribute is clearly the appropriate choice.  And I certainly see
increasing numbers of "gratuitously" non-empty alt attributes,
which do seem to reflect authors or designers who have heard of
the technical requirement for alt attributes but don't really
understand their practical implications for people with

> 5. Tables for layout
> Some of our older sites use tables for layout of navigation panels, but
> they linearise OK on browsers
> that don't support tables.
> Is this accessible or not? I think it is.

Well, of course "accessible" isn't a binary property.  It may not
be a *severe* barrier, but it's not ideal either.  The catch is
always that a user has to now guess whether to attempt to use
"real" table navigation or not.  If they can be sure that all
tables are for layout only and can be safely linearised then
that's fine.  But how are they to find that out?  A slight abuse
of the table summary attribute might use it to say "layout table"
- but if there are lots of these, and especially if they are
nested, this rapidly gets tedious.

So, on the one hand I wouldn't get all that excited about tables
used for layout on legacy sites ( at least if not nested, and
they linearise sensibly); but I certainly wouldn't want to see
layout tables in any new development.

>  6. Identifying link targets clearly One of the sites we
> designed (www.teagasc.ie), has a left navigation panel where
> the same word is used on links to 2 different target pages.
> e.g. Environment (in the Advisory and Research sublists).  This
> is explicitly at the request of the client, since that is how
> their organisation is structured, and they don't want to use
> different names for corresponding sections within different
> divisions.  We put different text in the A/@TITLE attribute to
> try and surmount this problem.  Does this satisfy the
> checkpoint? I would argue yes in this case, although it is
> certainly debatable.

Um ... I think it's "debatable" only in the sense that some
prominent automated checkers get it wrong.  There is no explicit
requirement in WCAG 1.0 that says that links with the same link
text must point at the same text.  This is stated *only* in the
HTML techniques document which says:

  If more than one link on a page shares the same link text, all
  those links should point to the same resource. Such consistency
  will help page design as well as accessibility.

but which then adds, in the very next sentence:

  If two or more links refer to different targets but share the
  same link text, distinguish the links by specifying a different
  value for the "title" attribute of each A element.

So there is absolutely no basis in WCAG for preferentially
requiring only the first of these techniques.


As one addition to Eoin's list, I would mention the practice of
offering "text only" versions of a site as a route to achieving
accessibility.  There was a time when this was positively
fashionable, but I would have hoped that understanding had moved
on to embrace proper "mainstreaming" and "universal design".
Nonetheless, I am still seeing *new* site designs prominently
displaying a "text version" button as if it is something to be
proud of.  (In some cases this seems to be on the basis of snake
oil from some vendors of tools to automatically generate such
"text only" versions - which are sold on the basis, explicit or
implicit, that this somehow magically resolves all accessibility
issues with arbitrarily designed sites...)


Anyway, as I say, just my tuppence worth - I would be very
interested in other opinions.

Best - Barry.

More information about the CEUD-ICT mailing list