[Irl-dean] False Accessibility Developers

Tim Culhane tim.culhane at criticalpath.net
Tue Mar 28 09:38:07 IST 2006


With reference   to how to Identify link targets clearly,  I personally
believe that this comes down to context.

If the target  can be established from the context in which the link appears
then I see no problem with using  links with the same name which point to
different locations.

However, this is extremely subjective and would require hands on user
testing to verify.

One example of where context is not easy to determine is where users use the
list of links dialogue in jaws.

 Given that user testing is not always fully used, on the whole I would
strongly urge developers to clearly distinguish  link titles.

Many blind users, especially beginners, will be confused if one or more
links on  a page have the same name but point to different locations.

Indeed, I doubt that sighted people would be too clear either  if they see
two links  both pointing to 'environment' but end up in different places?

if using the list of links dialogue in jaws, it is impossible to  determine
any  context from the link titles.



-----Original Message-----
From: irl-dean-admin at list.eeng.dcu.ie
[mailto:irl-dean-admin at list.eeng.dcu.ie] On Behalf Of Barry McMullin
Sent: 27 March 2006 20:34
To: irl-dean at list.eeng.dcu.ie
Cc: mcmullin at eeng.dcu.ie
Subject: Re: [Irl-dean] False Accessibility Developers

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
- 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

>  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.

Irl-dean mailing list
Irl-dean at list.eeng.dcu.ie http://list.eeng.dcu.ie/mailman/listinfo/irl-dean

More information about the CEUD-ICT mailing list