'

[Irl-dean] False Accessibility Developers

Eamon Mag Uidhir eamon at maguidhir.com
Mon Mar 27 16:40:51 IST 2006


Eoin is identifying a key dilemma for developers -- having to compromise 
because the client doesn't completely "get" accessibility. While the 
developer may know where the bodies (the compromises) are buried, the 
chances are nobody will ever ask -- the pages will stand or fall on the 
basis of a quick mechanical going over with Bobby from somebody who may 
not be very expert at interpreting the results. Very carefully built 
sites get bad reputations for no good reason this way.

In the instances mentioned, I believe it's possible to subset XHTML 
sufficiently to stay out of trouble with particular browser situations, 
e.g. Lynx and IE6. We already ignore some elements of the spec because 
no known browser supports them. Sometimes you have to leave some of the 
tricks in the box. I would always be striving for XHTML so the content 
can be parsed and machine-processed as XML later on.

Strict doesn't necessarily mean "better". It really means narrower in 
definition and functionality. Sometimes Transitional is right because 
the page wants to do something Strict won't allow.

PNG alpha transparency is still badly treated in certain browser 
situations, so it isn't universal yet. I'd hold off.

JAWS seems to be supporting empty alt text well enough nowadays. There's 
no case for just leaving out the alt parameter though.

A compromise for simple navigation tables is to put in a summary to 
explain what is going on and also to provide a skip link. Nesting layout 
tables is the real accessibility killer.

With the duplicated link texts, this probably needed just a little bit 
more evangelism with the client. There's always a Man from Del Monte who 
will OK accessiblity solutions, if he can only be reached. Sometimes 
it's the marketing guy, sometimes the technical guy, the task is to suss 
out who to make the strongest accessiblity pitch to. The varied title 
tag was definitely a good solution, but open to demolition in a 
machine-validation check where there's no opportunity for special pleading.

Eamon




Eoin Campbell wrote:

>I don't think there is a simple answer to this problem.
>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.
>
>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.
>
>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.
>
>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.
>
>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)
>
>
>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.
>
>
>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.
>
>
>
>While I completely agree with you that many developers incorrectly claim
>compliance,
>I would need to look at the sites in question before condemning them
>utterly.
>Hanlons Law (http://www.usemod.com/cgi-bin/mb.pl?AssumeStupidityNotMalice)
>applies:
>
>"Never attribute to malice what can be explained by stupidity. Don't assign
>to stupidity what might be due to ignorance. And try not to assume your
>opponent is the ignorant one -- until you can show it isn't you."
>- M. L. Plano
>
>
>
>brendan spillane wrote:
>  
>
>>Recently I have come across cases where website developers are falsely
>>claiming accessibility for the websites of some organisations.
>>
>>  
>>    
>>





More information about the CEUD-ICT mailing list