RE: Template for Accessible Web Page

Matt Morgan-May wrote:
>> * Invalid
> [MM] Yes, there are some bullets missing alt text, and that shouldn't
> be, though in reality it doesn't affect the overall accessibility.
> But do superfluous attributes here and there really make a document
> inaccessible? Be careful of your answer:   


As you know, there is accessible and then there is "compliant", and often,
in a world of required tick boxes, "compliant" is mandated.  I won't argue
the merits of this perspective/methodology, as most of us have been around
long enough to be able to discuss the pros and cons of this argument in our
sleep (newly arrived members to this list are encouraged to search the

However, WCAG 1, Priority 2, 3.2 clearly states: "Documents must validate to
published formal grammars". (...and that I type from memory)  

If the template has a DTD (it does), then it should validate to that DTD -
period.  Don't like the DTD in question?  Choose another, or write your own:

	 <!DOCTYPE HTML PUBLIC "-//Adobe Inc.//DTD Alt Text Issue//EN"

(Yes, writing a custom DTD is not for beginners, but it *can* be done, and
in the early days of the web there were numerous alternative DTD's flying
about. [])

One thing I've been doing at my current gig is going in and actually
downgrading Drupal "Themes" doctypes to HTML 4.01 Transitional, as the
WYSIWYG editors tend to pump out better HTML than XHTML; I choose valid over
"trendy" - as David D notes (and is well documented), "It is suggested that
XHTML delivered as text/html is broken and XHTML delivered as text/xml is
risky, so authors intending their work for public consumption should stick
to HTML 4.01". []

> [MM] This is required for standards mode in IE 6.

And see, this is why I find your position curious: clearly you want things
to "work", and yet the prescribed W3C method to ensure that things "work"
(use a standard) seems some-how not that important to you.  You state: "Be
careful of your answer", to which I echo the same advice - remember here
that we are talking about a "template", not a one-off page with an
un-escaped ampersand.  To cavalierly dismiss images with no alt text is,
uhm, against the grain - I at least am disappointed.


Meanwhile, Haileselassie, Antonio O. (HQ-LM020) wrote:
> And, you are of course
> correct with the current WCAG 1.0 guideline on scripts, but I don't
> necessarily agree with the antiquated guideline. It's too limiting
> when access can still often be accomplished using scripting properly.


Compliance.  (See above)

Then there is the issue of "fall-back" or degradation - if JS is not
supported, then what?  At least one source suggests to me that 5%+ users on
the web today are not using a JS supported user-agent
[]. Sometimes it's because of internal security
settings [], whilst other times it may be a
conscious decision on the part of the user: I recently discovered an
interesting fact - JavaScript is murder on hand-held user-agents (english =
cell phone browsers), and can drain a battery at a rapid rate.  So one more
reason for being judicious in the use of JavaScript - I am predicting that
within 3 years 35%+ of all "web" traffic here on campus will be consumed by
mobile/hand-held devices, so I for one am watching this issue carefully.  

And so while the WCAG 1 guideline might be "antiquated" in your opinion, it
still has merit today, and again if you *must* be compliant to the WCAG
(mandated), it is not a trivial matter.  Use JavaScript if you must, but
ensure that things continue to work when the 5% of users visit your site.
Proper scripting allows for core/key functionality to remain regardless of
user-agent settings (which is how I interpret the guideline: "Ensure that
pages are usable when scripts, applets, or other programmatic objects are
turned off or not supported.").

John Foliot 
Academic Technology Consultant 
Stanford Online Accessibility Program
Stanford University
Tel: 650-862-4603

Received on Tuesday, 25 March 2008 19:58:36 UTC